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
No combination of WebDriver for any version of Chrome on Linux
works 100% correctly.
Remove the failing tests for now.
Change-Id: I46be2c2c857e93234c839d32f1c0d4224733d0f7
Move ve.track() subscriber to its own file, and have it
route mwtiming.* events (for TimingData) and mwedit.* events
(for Edit schema) differently. Most of the data population
lives in the subscriber, so actual ve.track() calls are
pretty lightweight.
Existing ve.track() calls with timing data were kept with
their names intact for backwards compatibility, but
we may eventually want to throw them out and start from scratch.
ve.init.mw.ViewPageTarget.init.js:
* Remove old track subscriber
* Track init and ready events
* Remove old ve.track( 'Edit', ... ) crap that didn't work
ve.init.mw.ViewPageTarget.js:
* Fire the saveWorkflowBegin event before the save dialog
loads rather than after
* Remove unnecessary this.events.trackSaveError() calls:
TargetEvents already listens to these events itself
* Remove badtoken handler because all it was was an
unnecessary trackSaveError() call
* Add abort tracking
** Pass trackMechanism through deactivate() and cancel()
ve.init.mw.Target.js:
* Add static.integrationType to populate the 'integration'
field in the schema
ve.init.mw.TargetEvents.js:
* Simplify onSaveError* methods away into connect bindings
* Map track topics to mwtiming.* so they can be routed separately
* Track save-related mwedit.* events
Depends on I978eda96c in WikimediaEvents
Change-Id: Iae677d9b15c71d2b18e795bd5179d11876c06abd
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
