In I19da270a we bumped the z-index for the overlay from 4 down to 2, to avoid
clashing with the toolbar. However, the site logo, search box and personal
tools all have a z-index of 3, so 4 is required. Instead, bump the toolbar's
z-index up by 1 to 5.
Change-Id: I7e1edcf05cde054c7bcb8c13b5633930fb5ed3b5
New changes:
7d8ed7f Copy in some IE CSS hacks from ve-mw
a2e962e Update OOjs UI to v0.1.0-pre (20c61ec865)
d99c62f Update OOjs UI to v0.1.0-pre (d4cfcce969)
7fe02b3 Fix lots of spelling mistakes and typos
Local changes:
Remove redundant IE CSS rules since core's I013688c5
Bug: 73565
Change-Id: Ic60cd5290932ec38fab26492fffa17c3a8e91398
However, ve.ui.MobileContextOptionWidget.js & ve.ui.MobileContextOptionWidget.css
do, so let's actually use those…
Bug: 73646
Change-Id: Ie79fe549f146e0dfdf775594092211ecf97bc13a
Make sure it always gets torn down on deactivate, not
just on save. Otherwise we end up with multiple copies of it.
Change-Id: I7b95c316641fc48ce7087a0042ec6174fe03180b
If you clicked "Read" while the editor was loading
(but only while the "Edit" tab was already active, not before)
then you could get in a situation where surfaceReady fired
on an already-aborted target, which caused JS errors.
It seems like we should clean more things up in this
case, but I don't know what they are. In any case,
we should not try to set things up on a non-activating
target when surfaceReady fires.
Change-Id: Id57bd63ff288156725e472e7d89009022090253a
Copy in the font-size:127%; rule from MonoBook's main.css which is applied to
div#globalWrapper
Caused by Id425c56d
Bug: 73660
Change-Id: I05502295b81c62fd1180dff860dea68d76c2dfa9
New changes:
6ae94bc Add tests for ve.instanceOfAny()
ea1ac17 Localisation updates from https://translatewiki.net.
a9a25cb Update OOjs UI to v0.1.0-pre (f1abca8e82)
ab55974 build: Update various devDependencies to latest
921d16a Localisation updates from https://translatewiki.net.
cdd2691 Use history as as global
Change-Id: I4ff70005591cac11c39e08a602457cf4e0eda9be
Follows-up Ica33de675, If505a46f54.
* The setting of 'uri' looked like a redundant local alias before
passing on to pushState, but is actually important on itself.
* Remove binding for hideLoading. It's a detachable method on
a singleton, not an instance method.
Change-Id: Ic3536caf3f42ee893124312fd5981b67336bd480
When you clicked the Back button in the browser, the URL
in the address bar would change (removing veaction=edit),
but we would not go back to read mode. This was broken
by 5c0c11753 almost a month ago but apparently no one noticed.
This is because 5c0c11753 moved the pushState() calls to
be earlier (in init init), making the replaceState() call
in the ViewPageTarget constructor (which is there
specifically for this bug) run too late in those cases.
The simplest way to fix this is to duplicate these replaceState()
calls before the pushState() calls in init init.
I feel a bit bad about copying code, but not very bad
because the code I'm copying already has a FIXME comment
about how there should be a better way :P
Change-Id: I6627a5d1d9377ae815bc58bceeb059ce9f4f19ab
Just like DOM interfaces such as document and location. And JS
constructors like Object.prototype, and libs like jQuery.
No need for the window host object.
Change-Id: Ie39aaea2ca17bdec5fb3afe32a4e6c9f751bd0c6
The location object is a global, just like document.
Using it via 'window' needlessly adds complexity and, for example,
makes it harder to catch typos in static analysis.
Standardise on location.href in place of the many different
variants for accessing and assinging the full url:
location =
location.href =
location.assign() =
And each with 'window', 'document' and without host object.
Change-Id: If88515bd88fc5b93ebacd4ec41fce02fec540f18
