Disclaimer: I work for or provide services to the Wikimedia Foundation. However, the Foundation does not vet all my activity, so edits, statements, or other contributions made by this account may not reflect the views of the Foundation.
Thu, Jun 21
We do already refer to the link text as "label" in other places -- e.g. a numbered link gets an "add label" button to swap out the "" for text -- that said, if people think it's unclear and needs explanation in this situation, now would be a good time to quickly change that before people spend effort on translations.
I do agree with matmarex's suggested approach. The issue here seems to stem from a lack of clarity (on my part, on reviewer's part, on the code's part, etc) about exactly when things are providing a mobile experience. Wiping that clean and getting a simple rule for it would make sense.
Tue, Jun 19
I found the simplest way to test reproducing this was to make a template which just contains a single link, include it on an editor page, and then use dev tools to outright remove the highlight node. Leaves the link easily accessible for clicking.
Mon, Jun 18
Fri, Jun 15
The overlay shouldn't be loading on desktop though. Overlays only really make sense on a mobile/tablet device.
@Trizek-WMF If Ed approves and merges the patch, it could all happen today. So the timeline is pretty much "once approvals come in", unfortunately.
@Jdlrobson The merged patches should mean that the case you show there will result in the full article appearing in the editor. You can see it on beta: https://simple.wikipedia.beta.wmflabs.org/wiki/Barack_Obama?useskin=minerva&action=edit
Thu, Jun 14
I've done some hunting down of this -- the issue is that the windowmanager div the toolbar is in has aria-hidden=true, which makes my tab isolation code assume that nothing in it should be treated as being visible for tabbing purposes.
For what it's worth, I'm thinking of this ticket as a two-part thing. Part one is the existing patches which will restore the ?action=edit behavior of getting the full text, and part two would be working out the right place to put the UI to expose it more thoroughly. (I'd argue that the edit button at the top of a mobile page next to all the other page-level actions should trigger /all, but there's probably an argument to be had here...)
Yeh the magic password bit doesn't help this problem. mobileeditorsuppress is not exactly easy to remember and is also hard to type on mobile. I personally don't think this gains much unless it's linked to in the interface.
@Deskana: That all sounds correct.
I've updated the patch for option 1 for now. (Since it's the simple just-make-it-not-bold adjustment.)
From @Deskana I guess? (It's mobile, but it's also editing, so...)
Wed, Jun 13
@Volker_E So, I feel like the styling now suggests that the action button is "inside" the input. (Maximally so in the field-with-search-icon case.) That makes it feel wrong to me when the field focus excludes the button. It breaks the "this is one unit" message that the no-spacing-shared-borders design seems to be going for.
That said, I just tried to reproduce this with the new steps, and it still doesn't produce the error for me.
It maybe looks a little weird with the focus highlight and the disabled action button. If @Volker_E would like to tweak that combination somehow?
The 400 is specifically "Unknown source".
Tue, Jun 12
@Trizek-WMF it truncates itself so it fits on one line.
Mon, Jun 11
I think building it as a separate context item which might not appear directly next to the link context item would be a bit confusing, just because it's explicitly scoped to act on the link annotation, whereas the pile-of-contexts is "all the overlapping annotations at this cursor location".
Okay, thanks for that! That sequence, and particularly the "xy" still being present, makes me suspect that we're failing to properly tear down the toolbar dialogs, so it's still holding on to a reference to the previous surface, resulting in the failure when we try to perform actions on a discarded surface.
It's less apparent in the screenshot there, but in the full MW-VE experience, having that separate-section styling helps to distinguish it from the preview a bit:
That patch makes it so that visiting a ?action=edit URL will load the full page's text in the overlay editor. Sort of a preserve-the-status-quo patch.
I've made T196915 for the edit-a-full-page issue.
Sun, Jun 10
A variant on that, which I think is probably overkill, would be to use the key styling from the help dialog:
Sat, Jun 9
Do we have any other shortcuts exposed in dialogs to be consistent with the styling of, or is this treading new ground? (Nothing springs to mind, but...)
Thu, Jun 7
I can't reproduce this, trying locally and on beta.
Tue, Jun 5
@Esanders Could be a side effect of 49a8fbae4 or 24e35e428... but it seems to be saying that node is null, which is weird since node = this. Or this.icon is null, in a path which has already verified it exists.
Mon, Jun 4
@Daimona: I'm not opposed here, but the MobileFrontend currently only does section-editing. The mimic'd behavior here is as-if you had visited the page and then clicked the edit button at the very top of the page. (I think this is quite confusing even without this action=edit behavior, naturally.)
@Bencemac: On the defaults front, as much as anything that's a UI question. Fitting the setting in, changing the setting later, etc.
Wed, May 30
@Deskana it's not merged yet, so I think what you're saying is that the current state of affairs before-this-patch needs changing.
Tue, May 29
May 25 2018
I don't think this is happening any more. (Or, it's not to me.)
I don't see this broken on beta / locally. Did it get fixed somewhere else?
May 24 2018
When we say "desktop editor" here, are we referring to Visual Editor, the 2017 New Wikitext Editor, or the classic desktop wikitext editor?
There, a patch in the name of having this be something people can test the experience of.
May 23 2018
A 1-2 pixel tweak applied to a few of these elements produces this:
I wound up doing more on this, at the hackathon. (Admittedly, not having seen Ed's patch, otherwise I'd have added to it instead.)
May 20 2018
@Ryasmeen: Testing for the merged patch should be on scrolling behavior. (The floating toolbar, find/replace search highlights updating, context items / inspectors open while scrolling.)
Doesn't seem to happen any more, so I imagine T187070 fixed it as a side-effect.
May 19 2018
May 18 2018
Relatedly, here we see it blending in with a multiple-annotations stack:
May 16 2018
Issue is subtle fallout from the async-promises change, I think?
May 10 2018
May 9 2018
I don't think we can make it not need an API request. We can make it use a different API request, though. Or we can decide we don't care about hidden-categories being hidden in the rebuilt markup. (Status quo is already it missing the categories from templates / auto-added stuff like pages-with-syntax-errors.)
May 8 2018
May 7 2018
May 2 2018
If it's always action.saveIntent.timing, that implies that when onSaveWorkflowBegin happens timing.ready is undefined.
Also, let's see...
May 1 2018
Here's the new state of that patch:
Apr 30 2018
Apr 25 2018
Apr 24 2018
Apr 18 2018
Apr 17 2018
Apr 12 2018
Snippet of your actual content in both modes does also have the drawback that we'd have to wait for it to run the round trip to the server for the conversion, as well.
Apr 11 2018
I'm sure people might want to give feedback on the wording of this.
Apr 9 2018
This resolves the wikitext / other-plain-text cases. The parent (T153315) is unaffected, since that's not text/plain.
Apr 5 2018
This does tend to be an error we see if Parsoid / Restbase aren't running properly, for what it's worth.
Mar 29 2018
This patch is a shining example of lots of debugging and history-trawling resulting in a tiny change.