@Deskana this affects the mobile visual editor as well. I've noticed this for many months now—I'm currently running Firefox 63.0b5 on Android 8.0 on the Moto Z Play Droid.

@Nickps, @Neil_P._Quinn_WMF - Can either of you confirm that this bug still exists? The scrolling code for mobile editing has been significantly refactored.

In T196839#5063002, @kaldari wrote:

@Nickps, @Neil_P._Quinn_WMF - Can either of you confirm that this bug still exists? The scrolling code for mobile editing has been significantly refactored.

I checked last week and it still exists in Firefox for Android 67.0b5. I also noted that it happens only in the mobile visual editor, not in the mobile source editor, so I've updated the description and title to reflect that.

As with all Firefox mobile bugs we have to prioritise based on current usage, which is currently 0.82%: https://analytics.wikimedia.org/dashboards/browsers/#mobile-site-by-browser

Is it possible that @Neil_P._Quinn_WMF is experiencing this now: T219200, which is happening on iOS Safari too. But that one is a regression and not on production yet, is this one happening on production?

It's happening for me in production.

In T196839#5063432, @Ryasmeen wrote:

Is it possible that @Neil_P._Quinn_WMF is experiencing this now: T219200, which is happening on iOS Safari too. But that one is a regression and not on production yet, is this one happening on production?

I've been seeing this in production for almost a year now and it happens consistently every time you try to place the cursor, so I'm confident it's not related 🙂

Thanks for bringing our attention back to this, @kaldari.

We have time set to talk about T196839 on Monday, 1-Apr, [1]. More specifically, to decide whether to work on it.

Next Step

• Report the outcome of Monday's conversation in this thread.

Ask

@kaldari, does the above sound right/ok to you?

Not an "ask," but if there are additional considerations you think we should keep in Monday during Monday's conversation, we'd be keen to hear.

1. Context: Monday's (1-Apr) conversation belongs to our upcoming quarter-long effort to resolve what we're calling "Critical [mobile] Usability Issues." Which – for the time being – are represented in this list that has not yet been prioritized.

In T196839#5068268, @ppelberg wrote:

Next Step

• Report the outcome of Monday's conversation in this thread.

Considering

• This issue unavoidably breaks editing for contributors experiencing this issue [and thus has the potential, albeit small, to impact mobile VE edit completion rate] [1]
• Firefox usage is small, but growing [2]
• Firefox usage is potentially greater among contributors [3]
• It is unclear how many contributors are potentially being impacted by this issue [4]

Next step

I think we should...

• Take <1 day to investigate what could be causing this issue

Resulting paths forward...

• If our investigation turns out solving this would be "straightforward/simple," I think we should fix it [5]
• If our investigation turns out to be anything other than the above, I think we should blacklist Firefox for mobile VE, communicate this decision on MediaWiki and, depending on the level of effort, implement something to communicate to contributors attempting to contribute on Android using Firefox that VE is not supported and suggest an alternative (Chrome)

1. Issue severity: @Neil_P._Quinn_WMF writes, "...it happens consistently every time you try to place the cursor..."
2. Firefox usage has doubled between: between 06-Jun-2017 and 07-March-2019: 0.3% --> 0.7% | User agent breakdowns
3. Firefox usage is greater among contributors: This is an assumption on my part built on thinking contributors to Wikipedia are more likely to use Mozilla considering its mission being adjacent/close/relevant to Wikimedia's and their approach to privacy. Doesn't necessarily further my point, but interesting: Wikipedians who use Mozilla Firefox & Category: Wikipedians who use Firefox for Android
4. Caveat to user agent breakdown data: as best I can tell, we don't know what browsers, operating systems and devices contributors are using. Although, maybe we can assume FF usage is equally small considering this issue has persisted for >1 year without our noticing/re-engaging with it.
5. Simple/straightforward: is one person spending < 2 days on this a fair definition?

In T196839#5099862, @ppelberg wrote:

4. Caveat to user agent breakdown data: as best I can tell, we don't know what browsers, operating systems and devices contributors are using. Although, maybe we can assume FF usage is equally small considering this issue has persisted for >1 year without our noticing/re-engaging with it.

We do actually have the ability to look at this: in various places we keep the user agents of contributors for the last 90 days only, so we could look at that to get an idea of whether contributors use Firefox for Android at the same rate.

I don't actually recommend doing it, since I think the benefit is too small for the effort required, but it is possible :)

It's slightly higher among editors at 1.6%:

Turns out this is a pure browser bug, nothing to do with our code. Any time you have an over-sized contenteditable input on FF mobile, tapping on it will scroll the page back to the top of the input.

Sadly that makes it much harder to fix.

We should file this issue upstream if it hasn't been already.

Change 502851 had a related patch set uploaded (by Esanders; owner: Esanders):
[VisualEditor/VisualEditor@master] Firefox Mobile: Prevent scrolling after mousedown

https://gerrit.wikimedia.org/r/502851

The above patch continuously restores your scroll offset for 1000ms after mousedown (timing determined by experimentation). We should see if this results in an acceptable experience.

In T196839#5102181, @Esanders wrote:

The above patch continuously restores your scroll offset for 1000ms after mousedown (timing determined by experimentation). We should see if this results in an acceptable experience.

Great. OK. @Esanders did you have a specific way in mind for testing whether we're satisfied with how this patch behaves? Options that immediately came to my mind:

• @Neil_P._Quinn_WMF and/or @dchan could test and post screen captures of the before and after
• I could test using the crossbrowsertesting.com trial account I have

The options above assume we have a way for interacting with the patch...

Deployed on prototype server: https://visualeditor-prototype.wmflabs.org/wiki/Pride_and_Prejudice

There is still a slight flicker whenever the cursor is placed anwhere past the first page of the document, but it is usually almost unnoticeable.

In T196839#5108112, @Esanders wrote:

Deployed on prototype server: https://visualeditor-prototype.wmflabs.org/wiki/Pride_and_Prejudice

There is still a slight flicker whenever the cursor is placed anwhere past the first page of the document, but it is usually almost unnoticeable.

At least on my device (the Moto Z Play, a roughly three year old midrange phone), the flicker was fairly noticeable. But it absolutely works, and that's plenty considering the use share.

Thanks, @Esanders!

In T196839#5101379, @Esanders wrote:

It's slightly higher among editors at 1.6%:

Also, out of curiosity, what dataset did you query to get this? I assume not saveSuccess events since I have a hard time imagining anyone saved given the current state 😛

Also filed upstream with Moz: https://bugzilla.mozilla.org/show_bug.cgi?id=1544133

In T196839#5108154, @Neil_P._Quinn_WMF wrote:

Also, out of curiosity, what dataset did you query to get this? I assume not saveSuccess events since I have a hard time imagining anyone saved given the current state 😛

Yeah, I used 'init' events for all of 2019.

select useragent.browser_family, count(*) as total
from event.editattemptstep
where
    event.platform = "phone" and
    event.editor_interface = "visualeditor" and
    event.action = "init" and
    year = 2019
group by useragent.browser_family

Surprisingly ready:saveSuccess rate is not actually that low on FF mobile at 18% (vs 24% and 30% for Chrome & Safari mobile respectively).

select sum(if(event.action='saveSuccess',1,0)) / sum(if(event.action='ready',1,0)) as rate, useragent.browser_family, count(*) as sample_size
from event.editattemptstep where
year=2019 and event.platform = 'phone' and event.editor_interface = 'visualeditor'
group by useragent.browser_family

In T196839#5108151, @Neil_P._Quinn_WMF wrote:

At least on my device (the Moto Z Play, a roughly three year old midrange phone), the flicker was fairly noticeable. But it absolutely works, and that's plenty considering the use share.

Just peered over @Neil_P._Quinn_WMF as he tested and I tried doing the same [1]. This is an improvement. Let's deploy. Good stuff, @Esanders

1. Tested on a Nexus 7 running Android 4.2 using crossbrowsertesting.com

Change 502851 merged by jenkins-bot:
[VisualEditor/VisualEditor@master] Firefox Mobile: Prevent scrolling after mousedown

https://gerrit.wikimedia.org/r/502851

Change 502846 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (a3a2c48f7)

https://gerrit.wikimedia.org/r/502846

Change 502846 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (a3a2c48f7)

https://gerrit.wikimedia.org/r/502846

In T196839#5108151, @Neil_P._Quinn_WMF wrote:

In T196839#5108112, @Esanders wrote:

Deployed on prototype server: https://visualeditor-prototype.wmflabs.org/wiki/Pride_and_Prejudice

There is still a slight flicker whenever the cursor is placed anwhere past the first page of the document, but it is usually almost unnoticeable.

At least on my device (the Moto Z Play, a roughly three year old midrange phone), the flicker was fairly noticeable. But it absolutely works, and that's plenty considering the use share.

Thanks, @Esanders!

Yes, the flicker is very much noticeable, and this happens for iOS safari as well after we fixed scroll jump for that, so maybe it's part of the fix that stops the jumpiness and could be improved. But since that's a different issue, we can maybe track that separately.

There is a case where if you tap somewhere on the article it does not scroll correctly to that position, it's either behind the keyboard or somewhere far down. So far I see it happening first time in every session. I think there is a bug about that already, but can't find it.

I will leave it up to @ppelberg to decide whether this can be closed given the above two issues.

iOS Safari flickering

In T196839#5178009, @Ryasmeen wrote:

Yes, the flicker is very much noticeable, and this happens for iOS safari as well after we fixed scroll jump for that, so maybe it's part of the fix that stops the jumpiness and could be improved. But since that's a different issue, we can maybe track that separately.

@Ryasmeen, tracking the iOS Safari flickering issue separately makes sense to me. This of course assumes doing so is helpful to you and @Esanders's workflows. If it is, are you able to fill in the steps to reproduce this issue in T224322?

...I've tried to take – what I think are – the right steps to reproduce the iOS Safari flickering issue without success. See: T224322#5211622

Android Firefox flickering / scrolling

In T196839#5178009, @Ryasmeen wrote:

In T196839#5108151, @Neil_P._Quinn_WMF wrote:

In T196839#5108112, @Esanders wrote:

Deployed on prototype server: https://visualeditor-prototype.wmflabs.org/wiki/Pride_and_Prejudice

There is still a slight flicker whenever the cursor is placed anwhere past the first page of the document, but it is usually almost unnoticeable.

At least on my device (the Moto Z Play, a roughly three year old midrange phone), the flicker was fairly noticeable. But it absolutely works, and that's plenty considering the use share.

Thanks, @Esanders!

Yes, the flicker is very much noticeable...

@Ryasmeen, does the video below represent the issue you are experiencing? If it does, I think we should close this issue considering:

1. The behavior in the video is a noticeable improvement over the behavior this ticket was a response to, "...the editor essentially unusable" and
2. The commitment we made to the amount of time and effort we would allocate to fixing this issue.

Testing

Browser: Firefox
OS: Android

🎥https://youtu.be/AVfQmkVejLs

Verified in FF 82, and apparently it was fixed in FF 76.

FF mobile usage is quite low and due to app stores, people update nearly instantly. I think we can just drop the hack completely. Here's the version chart for the last two months:

Change 640972 had a related patch set uploaded (by Esanders; owner: Esanders):
[VisualEditor/VisualEditor@master] Revert "Firefox Mobile: Prevent scrolling after mousedown"

https://gerrit.wikimedia.org/r/640972

Test wiki created on Patch Demo by ESanders (WMF) using patch(es) linked to this task:

http://patchdemo.wmflabs.org/wikis/e31da285bb597898374db33a83df80ed/w/

Change 640972 merged by jenkins-bot:
[VisualEditor/VisualEditor@master] Revert "Firefox Mobile: Prevent scrolling after mousedown"

https://gerrit.wikimedia.org/r/640972

Change 641813 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (a466243e6)

https://gerrit.wikimedia.org/r/641813

Change 641813 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (a466243e6)

https://gerrit.wikimedia.org/r/641813

(@ppelberg Looks like you tested this the last time, so I'm moving it directly to your column)

In T196839#6658012, @ppelberg wrote:

Out of curiosity: @Esanders does the graph you shared above come from here: https://analytics.wikimedia.org/dashboards/browsers/#mobile-site-by-browser/browser-family-and-major-hierarchical-view ?

Yes, somewhere on that page.

In T196839#6660018, @Esanders wrote:

In T196839#6658012, @ppelberg wrote:

Out of curiosity: @Esanders does the graph you shared above come from here: https://analytics.wikimedia.org/dashboards/browsers/#mobile-site-by-browser/browser-family-and-major-hierarchical-view ?

Yes, somewhere on that page.

Roger that.