We don't have a FOUC on the appearing of the 'edit' link. That
one is handled quite intelligently:
* Via the stylesheet that is also loaded in noscript mode, its
(hidden) appearance is already predetermined. So as soon as
those elements are seen by the browser they style correctly
for users without JavaScript (display: none).
* This same stylesheet also hides it for users with JavaScript
but where VE is not available (e.g. due to browser support).
While ve-not-available is added very early on (before
document ready), it could in theory cause a short FOUC, but
that's okay. We simply don't know that VE isn't supported
until then. We optimise for the common case (JavaScript
enabled, VE available), while still ensuring that it is
always hidden in noscript, and is hidden as soon as possible
when VE turns out not to be available.
For some reason, one small detail (the little bit of whitespace
added inside the brackets), was left out of this and was
implemented by adding the class 'mw-editsection-expanded' to them
from a document ready handler.
* First step, get rid of the script that adds this class and
use ve-available instead. That means they're styled
correctly much earlier (we add the class to <html> before
document ready). This can still cause a brief FOUC, though
in most cases they're correct from the start.
* Step two, make brackets expand by default for script users,
and let ve-not-available reset it. This way, like with edit tabs,
a FOUC will never happen for ve-available. And even for
ve-not-available, a FOUC is rare since we add it before
document ready via <html> look-ahead styling.
There was still a brief reflow jump because of negative margins
between two paint events. One was undoing the other at a later
time. These negative margins are a remnant of when we were doing
animations (follows-up I4b9c47fd65a70). They were added to reduce
reflows and content shift, but were now actually causing them.
Removed "padding-right" from mw-editsection, and negative margin
from the brackets.
Also:
* Don't add inline 'style="direction: ltr;"' on every single
editsection throughout the DOM. This was the only operation we
were doing unconditionally. While I doubt the need of it in
general, we can at least allow MediaWiki to do it right, and
only add the override if needed. This saves quite a few DOM
operations.
Change-Id: I7a729edc2cd4a66ebc0ad6935ffd02cb9b948bff
Make sure that each API request per file is delivered once. If the
file appears more than once on the page, the API request for
scalable details will be sent once and cached so there aren't
multiple API requests per image.
Change-Id: I68507a8ceb31b77dbf33d1074939ce6219cf076e
> JQMIGRATE: jQuery.fn.error() is deprecated.
While at it, also avoid using the overloaded .load(). It has
quite a few different signatures (one of them is to load $.ajax
by url and replace the contents of the element, completely
unrelated), and calling .on() directly is quicker as well.
Change-Id: I139b0c603577b5a0102d2ff679bd86b792830e3e
Note that I reported Bug 64655 for Chrome but upon refactoring
this test I find the buggy behavior now in Firefox but Chrome
is fine. Browsers are weird, and the Links inspector is too.
Change-Id: Ibd90a33bb43342dc1d7410d621f01875e1c177bf
possibly WIP
These changes make the test pass, still thinking about whether we
should test the workflow changes, which are cognitively different
than before
Change-Id: I85955836f0eeedcb55e7a5260101339d2f73d2e6
There was a slideDown() call, but this didn't do anything since
toolbars are visible and in the DOM by default.
As a temporary hack, hide it synchronously after creation and
then do the slideDown still.
This could ever so briefly cause a flash, though that didn't
happen in my testing.
This makes the experience smoother when we initialise the surface.
In particular the moment where we swap #bodyContent for our Surface
(which should look visually almost identical), before this change
it was still a bit of a flash since the Surface version has a
toolbar on top, and thus instead of swapping smoothly, we hide
content and show a similar piece of content that has an incompatible
offset from the top.
Bug: 64751
Change-Id: Id94974ba71fd887ce494d7b2b16ec62d43b18575
Get rid of all hard-coded values for both the target page
and also the text on the target page, which is now all set
in the .feature file.
Note that we're deconstructing the @make_selectable hook
by doing this. @make_selectable may become obsolete when
all the tests are refactored to use APIPage
Change-Id: Iad1b160d9d0274effb8504f276bd4816932d299c
Also adjust calls to InputWidget methods changed in
I324dfc2 in OOUI.
New changes:
9da32d7 Update OOjs UI to v0.1.0-pre (e6edd86d37)
b6aa671 Localisation updates from https://translatewiki.net.
1cba6e0 Update OOjs UI to v0.1.0-pre (9a6c625f5f)
94629f9 Localisation updates from https://translatewiki.net.
Change-Id: Id58d199c7ce3332a104ab2a5c395561ab94ae060
Using @edit_user_page hook is a workaround that avoids the
problem where Selenium brings up Firefox with the cursor in the
address bar
Change-Id: Iba42cbb74378952760db3db68130ac74219cde9b
this.transclusionNode doesn't exist. Also remove instanceof checks
as they are already done in #get(Selected|Reference)Node.
Bug: 64717
Change-Id: I7ff0133d1ad45edda8de2cbad459706dbaceb5f2
In two cases we were using fragment.getSurface().getFragment() which
creates a new fragment from the current selection instead of using
the range of the original fragment.
Change-Id: Ib41efe2ceb670a125c0c306d143e56f9b9c349e7
Adding a template by clicking the button without dismissing the lookup
menu first was leaving the menu open and inserting a template with the
query instead of the match.
Changes:
* If the lookup menu is visible, choose the selected item before using
the value of the lookup input
Depends on I3aa4e87 in OOUI
Bug: 64334
Change-Id: I22e04bd2d3628f03060d3734f9774b811c82f73b
