With this patch, the toolbar slides into place place nicely after
scrolling again, but it still occasionally flickers during the scroll.
* window.innerHeight is now smaller or something, and we have to
twiddle the scroll position by a larger value.
* document.body.scrollTop no longer works for setting or getting the
scroll position, so use different methods.
* requestAnimationFrame() now generates an insufficient delay to make
scrolling happen, so use setTimeout() instead. We actually have to
add a nonzero delay there, otherwise the toolbar sometimes doesn't
animate like it should or flashes in random places on the screen.
This delay is bad because the user can't start scrolling again
during that time, but I think we can live with that.
Bug: T233470
Change-Id: I6c40ee8ce5994e12eadb085bbffd120ef160d4ee
New changes:
4af3f84f7 Mark surface as "showAsDeactivated" when opening a window
79eb0e4e5 ve.ce.Surface: Guard against focusing a un-initialized surface
4124c275e [BREAKING CHANGE] ve.ui.TargetWidget: Construct a real target inside the widget
Local changes:
* Use new target widget
* Remove calls to deprecated methods
* 'surfaceReady' event was upstreamed
Bug: T236400
Change-Id: I765d657c172d96c3b2e2ae5998083e4926a31f15
As of commit c65ed0e7a8ac5f32a3a6e4cb2760dae03e4fca22 in MobileFrontend,
it uses errorformat=html queries (the same as we do), so we no longer
need to massage the responses to make it happy. The same commit also
turned parseSaveError() into a no-op, so we can remove that as well.
Change-Id: I4f0109ce120ebf94e5709d47d775a8178ce216fa
The call to selectFirstContentOffset() below would re-activate the
surface and (attempt to) show the keyboard if the surface was
deactivated, but not shown as deactivated.
This might have worked correctly by accident before
I39fe44eee8eab7129340bcff796b6b9b3a59a398 in VE core.
Change-Id: I500309cc0aa8cd794175ae683a17c2614fd58cc9
Some post-save scrolling would try to access the view before the
handlers were cleaned up.
Bug: T232347
Change-Id: I30433ef027c52d541351972f8ebb09fe6d45e436
As of I6c043e039fbef62a56f475b0dc365e171ab7bf59, this method is never
called. It was previously used to update the size of the toolbar when
context menus were displayed inside it, but they are now displayed
elsewhere.
Change-Id: I53030de1203a7f0d75780ae796bbb10082d5ef7a
As of I2f2495ab6c10116a6660f4361e49272cb95b988a in MobileFrontend,
the overlay never uses the default spinner.
Change-Id: Ie0aa624e33a5bd21fc20459697cca175d9de5606
When saving fails for a reason we don't handle explicitly, the error
message will have HTML formatting and will respect any on-wiki
overridden messages, rather than being plain text generic message.
Extensions providing custom SaveErrorHandlers may need to be updated.
The only one in Gerrit that requires a fix is TitleBlacklist:
Ibeae79c95557a7af699716c9d921f34c310bee6d.
* Remove handling for errors returned in .visualeditoredit.edit.info
rather than .errors (.error in old format). AFAIK this is only used
by some extensions, it is probably incorrect to do (T229539) and all
extensions I know of that do this (AbuseFilter, SpamBlacklist,
ConfirmEdit) have custom SaveErrorHandlers.
* Remove custom error messages for 'readonly' (identical to API
response) and for 'hookaborted' (very unhelpful and there is a
chance that the API response is better, if the extension causing
this error generates any error message).
* Add a silly shim for MobileFrontend integration, because we allow it
to handle error responses, and it expects them in the old format.
This is probably subtly wrong in many ways, but MobileFrontend code
only uses this for logging, so it shouldn't explode. In the future
we will hopefully change it to use errorformat=html (T228897#5366960).
Bug: T229532
Change-Id: I3b9c4fefc0869ef7999c21cef754434febd852ec
New changes:
854a1fa2c Distinguish active link styling
Local changes:
* Pull through active link styling
Bug: T228220
Change-Id: I925f88d32a514a749b96f501a211003bc4c924f0
New changes:
a06204317 Fix TableNode unit test getOffsetFromCoords failure on Firefox
dfe0eb025 Refactor mobile context logic into ve.ui.MobileContext
Local changes:
* Pull through for edit cards refactor
Bug: T227532
Bug: T228767
Change-Id: I6c043e039fbef62a56f475b0dc365e171ab7bf59
New changes:
1a7460058 Remove ve.newMobileContext feature flag
Local changes:
* Remove ve.newMobileContext feature flag
Change-Id: Ia8def997b7cba4623866080752b06068d2118cc3
* Remove animation for toolbar sliding into place. It now happens on
the fake toolbar in MobileFrontend shown before the real toolbar
loads, and our toolbar just transparently replaces it.
Bug: T217784
Depends-On: If21aa0ea619ec2500ce5fca6fe81eb27f26bb047
Change-Id: Ib6ff7594e1982d1b46e9ca89d6b9722d025e8207
Abandon warnings are already handled by the code in MobileFrontend's
EditorOverlayBase. Using window.history.back() causes that code to run.
Having a duplicate way to trigger them only results in inconsistencies
because our dialogs animate in a different way.
Bug: T222315
Change-Id: I19c5616a6aeecf0ac63f37a564ef44f11df010b0
* Remove 'discardChanges' from switchToWikitext. This was
intended to discard changes even when the document was
modified, but it is no longer used as we always keep
changes if we can.
* Remove 'leaveVE' param, it was only used once and has
been replaced with a direct call to switchToFallbackWikitextEditor.
* Don't reset 'section' if there are no changes.
Bug: T221981
Change-Id: Ia39345da44d203ba67ae331917c8d5ece7d42ef7
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
Icon name changed from 'previous' to 'close'.
This matches MobileFrontend's wikitext editor and other overlays.
Bug: T210630
Change-Id: I5f588c65887dd2247d3f816959807f943215e0c3
Cite's a08febb0afa2d changed the rules for adding the Cite button to the
toolbar – it now requires a placeholder slot in the toolbar, rather than
finding the link tool and adding itself after that. As ve.init.mw.Target
was updated for this it kept working on desktop, but MobileArticleTarget
completely overrides the toolbar, and was missed.
Bug: T195191
Change-Id: I55c9de9e736bb83f5f05028f2fc07af0ad996050
Pass through the current document when available, otherwise
assume the current surface's document.
Also add a getter for getPageName, so that can vary based
on the target document.
Bug: T193856
Change-Id: Ifdc951fdc6a43b924d102e3fcd7e59e52023757b
Other page state is read directly, rather than passed in.
If we come up with a use case for passing this in at a later
date we can reconsider the best way to do this.
Change-Id: Iee7e608c969776b89dbb38b3b56a5177e48344af
Pencil is the icon we use for 'edit' elsewhere in the UI.
Use the eye icon for the VE tool to specify 'visual'.
Bug: T116417
Change-Id: I12b6bab2a52758685abde04579b274a32d651174
To align with the linked patch in MediaWiki core. Taking advantage of
the opportunity to use core's messages for these, and remove some dead
wood old messages that were never used like "restore" items in mobile.
Bug: T139033
Depends-On: Ie81b5edd275963a965cd44d0fd325cae9ee2f1a6
Change-Id: Ie00e94cc77cb750a7e8d1104366bb3dad65af8a4
Move over logic which isn't specific to the article
implementation of VE (e.g. nothing related to loading/saving).
Refactors setupSurface to use an abstract tracking method (which
does nothing by default), and moves surface CSS classes to #createSurface.
Breaking change:
* Rename onSurfaceReady to surfaceReady. We shouldn't need to listen
to our own events.
* Rename onReady to documentReady. onReady is not a listener.
Bug: T97166
Change-Id: I7242b1bb5501b7755a18a13d13e166c30cac9cdd
This makes way for a base mw.Target class which is
not specific to articles (e.g. Flow boards).
Bug: T97166
Change-Id: If72650bdf87aa9f195b004da0a4d815f1a8063a3
Right now .initialize() doesn't do anything other than enable
the window resize handler for toggling the "narrow" styling,
but as a matter of principle we should call .initialize()
on toolbars after attaching them.
Change-Id: I419c943d1d20af2105b84b8f5fbccc7070af601b
