Fix font-path

[guoyunhe]

This fixed a font loading error, which may lead to the non-styled page issue. I have checked in Firefox and Chromium. But we still need to test on en-test.opensuse.org

What browser are you using @cboltz ?

[guoyunhe]

@cboltz Can we deploy this PR to en-test.opensuse.org ? It should fix some problems that cause fonts loading failure and unstyled page.

[cboltz]

Deployed to en-test.opensuse.org - sorry for the long delay!

To answer your browser question - I use Konqueror and Firefox.

Unfortunately a quick test shows that Firefox still loads the page unstyled, and fixes/re-renders it after a second.

I also adjusted the setup a bit to make test deployment easier (en-test.o.o is now deployed from this git repo instead of using the mediawiki_1_27-openSUSE package) so that I can simply git pull now. This way has a few limitations (for example, I needed to add several symlinks), but it's probably better than the workarounds I used before. (The production wikis will continue to use the packaged version.)

Actually switching to git for en-test.o.o has another advantage - I'm able to git bisect, and just did ;-)

The result is:

cc63ab69145f07d6608f98594c0040ea93d1e9e2 is the first bad commit
commit cc63ab69145f07d6608f98594c0040ea93d1e9e2
Author: Guo Yunhe <guoyunhebrave@gmail.com>
Date:   Wed Jun 27 23:01:37 2018 +0300

    Auto focus in login modal

:040000 040000 56ec891d6fc47ed88f747c040dd97346183f3d20 7c63e59e02766c5787ead60d21ed0d347126edc2 M      skins

I'm a bit surprised because this commit looks quite harmless to me, but double-checking confirmed that it really introduced the issue.

I hope this helps you to find out what causes the unstyled rendering.

[guoyunhe]

MediaWiki is surprising sometimes. It uses a complex caching strategy and assets bundling strategy.

I have tested on my Firefox and Falkon, but cannot see the unstyled page. Network analysis is normal. No failed/slow requests.

Can you try with Falkon and Chromium? Or web browser in your smart phone? I will also invite other people to test the page.

[guoyunhe]

@cboltz I asked my friends and some openSUSE community members to test it. Most said it is alright. Tested with:

1. Firefox + openSUSE Tumbleweed. Okay.
2. Falkon + openSUSE Tumbleweed. Okay.
3. Chromium + openSUSE Tumbleweed. Okay.
4. Firefox + Android. Okay.
5. MS Edge + Windows 10. Okay.
6. MS IE 11 + Windows 10. Okay.
7. Safari + macOS 10.13. Okay.

[cboltz]

Strange. Am I really the only one who sees this? ;-)

To give you some more details: I see the issue with Firefox 57.0.4 on a (sadly outdated) Tumbleweed. I also tested with a clean Firefox profile (to ensure that none of my extensions influence this) and can reproduce it also with the clean profile.

I can't reproduce the issue in Konqueror or Chromium, which means it's limited to Firefox or even my limited to the old Firefox version I still use.

Can you do another test with https://en-test.opensuse.org/Main_Page?debug=true ? This will give you uncompressed JS and CSS and disable some caches, which might show the unstyled page a bit longer.

Maybe you should temporarily revert the offending autofocus commit so that we can deploy the other changes to production (which make sense and improve the wiki), and then re-add the autofocus?

There's another small detail I noticed - having the (now more visible) "Log in" button next to the search box might be confusing. (I realize you just moved both from the top right corner to the nav bar and changed the styling.) I'd propose to:

• keep the search box in the nav bar
• move the log in button back to the page actions, maybe right of "History"

For bonus points (whenever you have some time), maybe we can save one click for 95% of the login usecases. Instead of displaying a dropdown "log in / create account", what about displaying the login dialog instantly, and add the "create account" link to it?

I did a quick&dirty mockup to show what I mean:

[guoyunhe]

For the CSS issue, at least two other persons can reproduce it. (one has shown me a video.) However, I still cannot reproduce it in my system. I will check MediaWiki documentation of module bundling. We can even skip it by just insert <link /> tag manually.

For the UI changes, I mostly agree. Login button can be in the navbar, too.

[cboltz]

Maybe I should explain why I think the login button has a confusing placement: It sits next to the search input field, and I'm quite sure lots of people will enter a search term and click it - based on the placement, I'd expect it to be the "search" button ;-)

Since login is somewhat related to the page actions (especially "edit"), I thought placing the login button there makes more sense and avoids this confusion. If you find another way to solve the confusion (or think it isn't confusing ;-) that's of course also ok.

[guoyunhe]

@cboltz Finally I can reproduce it in some old version of Firefox:

1. Firefox 52 (Tor version): Yes.
2. Firefox 57: Yes.
3. Firefox 62: No.

I did some search in Mozilla's documents and Bugzilla to locate the reason. Then I found https://bugzilla.mozilla.org/show_bug.cgi?id=1404468 which explains this is caused by autofocus HTML attribute. Firefox used to handle it incorrectly and broke style loading. It doesn't matter network speed or caching problem. The autofocus was introduced with the commit cc63ab69145f07d6608f98594c0040ea93d1e9e2 you mentioned, to auto focus the login form input.

So the solution is easy, just remove the autofocus property and use some JavaScript to do the same thing.

I will make a new pull request. Login button position will be improved in the same PR. I think I got some good idea. Sorry for bothering in weekend.

[guoyunhe]

See #26