This code is supposed to check if we have scrolled past the end of the
page, and if we did, scroll back up to a more reasonable position.
However, it seems to incorrectly trigger in other cases, and scroll
the page back to the top, because getBoundingClientRect() occasionally
still returns bogus values (even though we try to avoid that). This
happens inconsistently when focussing the surface or closing a dialog.
We can't correctly display the toolbar while scrolled past the end of
the page. Removing this code causes it to go into an endless animation
loop in that case. But that may be preferable…
Bug: T219200
Change-Id: I152f2b39351ffd3c9799eea33cce95e05d2f9ab9
We need to set 'padding-top' matching the height of the toolbar
somewhere, so that the toolbar doesn't cover the top of the editing
surface. Apparently moving it from the current place (the top-level
wrapper for the MF overlay) to the document node (the node with the
'contenteditable' attribute) allows Safari to properly scroll the
cursor into view when focussing, rather than scrolling it offscreen.
Bug: T219066
Change-Id: Iee1e03bce24c2f149a0aa0f393a37b9db43eaca6
The edit might have changed the section title, which will change the
section-hash, which will make the redirect break. The only way to avoid this
is to use the HTML provided to saveComplete to check for the new hash.
Bug: T213120
Change-Id: I5adfdb44a8304ed4f30def74400e4512e9e8c0ae
It appears that I did a Ctrl+X in one file, but forgot to Ctrl+V in
the other. And no one noticed that 100 lines of code went missing.
Follow-up to 73561f7aba.
Bug: T218946
Bug: T219041
Bug: T219043
Change-Id: Ib1fd85d121083239397698ff1a30a7908deca25f
ve.init.Target#isToolbarOverSurface has been removed in VE/VE in 2016:
8b1208cb976278bd44025e6d2c86a3ea6ed8c177. Nothing calls this method.
Change-Id: I9640978b45e568412db4b1c5aa80631a68d847b2
On iOS Safari, when the keyboard is open, the editor toolbar could
previously be scrolled out of view, due to how the keyboard affects
the viewport (or rather how it doesn't).
Detect when this happens and bring it back in, with a similar slide-in
animation as when the editor loads. Technical restrictions prevent us
from really keeping it in view at all times, and I think this is the
best we can do (and it looks almost intentional).
Bug: T218414
Change-Id: I5eed360d4644815bc9829fbc6b0ffd79b205d10b
It will be easier for us to maintain this way. The code I'm moving had
a lot of comments saying that it should be moved here.
See MobileFrontend change Ibe192360bdecab86519de1781f66f90a3441c551.
Bug: T218946
Change-Id: I908e035ec245a9b190f05e64c35dbb29936434de
It was here because our old hacks prevented the viewport from being
scrolled, so the keyboard would always cover the last few lines of
the surface. But it is no longer necessary after we ditched the iOS
scrolling hacks in MobileFrontend.
Bug: T217769
Change-Id: Iaf3f86c0fc43f75d11a43462721f44d62abc6eb3
This is no longer necessary and doesn't work after we ditched the iOS
scrolling hacks in MobileFrontend. And the default implementation works!
Bug: T218429
Change-Id: I5fba78a3877901dac5afda46d3004c07cad383d0
Catlinks is hidden via a class when there are no non-hidden categories on the
page. We thus need to toggle that class depending on the categories
added/removed from the page.
Bug: T213528
Change-Id: I4067c5721c28041542b9ef2dbc796fbc41b1afe8
This code, added in 703b2c2ed0 (2015),
is no longer necessary.
// Disconnect the tool factory listeners so the toolbar
// doesn't start showing new tools as they load, too
// much flickering
this.getToolbar().getToolFactory().off( 'register' );
Introduction of targetLoader (d371014e5d)
resulted in all tools already being loaded before a Target is
constructed, so this is definitely not needed.
// Disable all the tools
this.getToolbar().updateToolState();
The tools are already disabled because we set the surface to read-only
above, so this does nothing.
Change-Id: Idb162b60891cd1b961e29d2b9f62b74908f17957
Previously, we tried to keep the list of category members and the file
thumbnail, history and metadata visible while the editor was open.
I am removing it because:
* It is not very useful, as you can't interact with them (e.g. links
are unclickable).
* It is inconsistent with the wikitext editor (except for non-existent
category pages, and I'm proposing to change that behavior in T139191).
* It causes issues when other code doesn't expect the special setup
for those pages (T194068).
This introduces a minor change to the handling of normal pages: after
the save, instead of replacing all contents of #mw-content-text with
the new page content, we only replace the .mw-parser-output child.
Normally the effect is the same (it's the only child), but this could
theoretically affect interactions with other extensions or gadgets.
Bug: T194068
Change-Id: I26cc82d3e0f0d64e3f18a80d232005fc7ab3b374
Icon name changed from 'previous' to 'close'.
This matches MobileFrontend's wikitext editor and other overlays.
Bug: T210630
Change-Id: I5f588c65887dd2247d3f816959807f943215e0c3
* Move (de)activationComplete up to ArticleTarget
* Mark (de)activate to be deprecated in the future
* Fix some properties to ensure target.edited is boolean
Change-Id: Ie34139cb68f90f34eb243f1bb964ef578e90dfb2
* Also make sure block notices have type 'block'.
* Remove old flag for tracking since we'll be using one
from core
Change-Id: I4b66e73c8a4c4dd7bffd7c0239b1d5ec06eed12f
Depends-On: I6bd1c95548616677e1f72ba6bcfc6f2b551c1ca6
When an edit notice is passed through from the API, allow
a type to be specified, and specify type 'block' if the
notice is a block notice.
If VisualEditorTrackBlockNotices config is true, track
when a message with type 'block' is shown.
Bug: T209633
Change-Id: If5fecc2c2c1c39f4b7245b9a215e1120c93b2b22
* Make inserting secondary tab work with Minerva's non-standard structure
of navigation menus
* Distinguish primary and secondary tabs with tiny icons, since Minerva
hides their text
* Hide section edit link dividers (unnecessary when we use icons)
Bug: T208102
Change-Id: Ieaec60165617e3b423ec58857d6f0a0406e22b1d
