Closed Bug 1661897 Opened 2 years ago Closed 2 years ago

Problem with Editor on Firefox 80.0

Categories

(Core :: Panning and Zooming, defect)

80 Branch
defect

Tracking

()

VERIFIED FIXED
82 Branch
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox79 --- unaffected
firefox80 - wontfix
firefox81 + verified
firefox82 + verified

People

(Reporter: matteo.sindona, Assigned: kats)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

Go here https://results.totallympics.com/forum.php?mod=post&action=edit&fid=100&tid=2897&pid=43871&page=1

Login with
Username: test
Password: test

Actual results:

When selecting text, both in the table or plain text, you get moved randomly around the editor

Expected results:

Until Firefox 79.0 selection was perfectly fine, you selected text or cells without any problem

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → DOM: Editor
Product: Firefox → Core

I am sorry, this was my problem. I tried with another PC and it works fine. You can close the ticket, sorry again!

EDIT: Sorry again, the problem is real. It's happening also on another PC

Here is a video of the problem: https://youtu.be/rZupNN7MvFw

To reproduce the problem with the same text, go here: https://results.totallympics.com/forum.php?mod=post&action=edit&fid=100&tid=2897&pid=43880&page=1

And login with
Username: test
Password: test

As you see until minute 0:10 everything is fine. But then if I click on the "Code" button to get the BB code of the text and then I click it again to go back to the "visual" editor, the selection is now a mess: I select the first line and it automatically gets me down (I am not scrolling down with my mouse).

This was not happening until version 79.0. Could you please have a look at this problem ? Why after I click on "Code" and I go back in the visual editor the behaviour of the selection is different?

The same applies for the selection of the rows of the table: if I select a row I get automatically moved towards the start of the table.
Video of this problem: https://youtu.be/mZs9fuhVJWU

Does this happen to you as well?

Thank you!

Same problem happens with Firefox Nightly 82.0a1. Selecting elements from the editor of that website is really a nightmare :(

I can reproduce the issue on Nightly82.0a1 windows10.

STR

  1. login https://results.totallympics.com/
    Username: test
    Password: test
  2. Go https://results.totallympics.com/forum.php?mod=post&action=edit&fid=100&tid=2897&pid=43880&page=1
  3. Scroll to anywhere
  4. Click "Advanced Mode" icon on the right end of toolbar if any
  5. Enable "Code" checkbox and then disable it
  6. Attempt to select "Open 5.5 Metre" at top of editing page

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=efa2336315eda0aaf78c2e94d6c9c98106ea136b&tochange=17dcdaec53ae5bb0f15105cabcc0235e49512679

Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Ever confirmed: true
Keywords: regression
Regressed by: 1644567

Hello Alice, thank you for your reply.

Yes, I forgot step 4., because my account has the "advanced mode" as default.

Do you think this is something which can be fixed in the next releases ?

Thank you!

[Tracking Requested - why for this release]: text selection is broken on famous web editor

TinyMCE editor is also affected.

STR

  1. Open https://www.tiny.cloud/docs/demo/full-featured/
  2. Scroll the edit page to bottom
  3. Click [HTML] at top of the editor
  4. Click [TinyMCE]
  5. Scroll to top and Attempt to select "Welcome to the TinyMCE Cloud demo!" by mouse drag selection
Flags: needinfo?(kats)

I'll investigate

Assignee: nobody → kats
Flags: needinfo?(kats)

Thank you guys.

I have noticed 2 more things:

  1. The problem does NOT happen if you switch between the normal mode and code mode WITHOUT touching anything else. But as soon as you click something on the table or on the code the first time, then the problem appears.

  2. You can make another test here: https://results.totallympics.com/forum.php?mod=post&action=edit&fid=100&tid=2897&pid=43915&page=1

  3. login https://results.totallympics.com/
    Username: test
    Password: test

  4. Go https://results.totallympics.com/forum.php?mod=post&action=edit&fid=100&tid=2897&pid=43915&page=1

  5. Click one cell inside the table with your mouse

  6. Click "Advanced Mode" icon on the right end of toolbar if any

  7. Enable "Code" checkbox and then disable it

  8. Go down on the table to view athletes ranked 20th-30th (or any other number)

  9. Start selecting the row of the athlete ranked 25th (or any other row in the middle of the part of the table you see on your screen

  10. You will automatically be moved up on the table, which should clearly not happen and was not happening until Firefox 79.0

I hope this helps! Thank you!

Seems like the problem is that when we restore the scrollframe, we set a pending visual scroll offset here but then it never gets cleared. The mechanism that's supposed to clear it is (a) this acknowledgement and (b) this clear call but (a) is conditional on aIsRootContent which is only set for the RCD-RSF.

So in summary we're setting a pending visual scroll offset on the RSF of a non-RCD, and never clearing it because the condition to clear it only happens on the RCD-RSF.

Hello Kartikaya,

is it possible to fix this for the next Firefox releases ? It is extremely uncomfortable and this behaviour of the editor drives me crazy :D

Thank you!

I'll definitely have a fix for FF 82. Depending on how risky/complex it turns out to be we may uplift it to FF 81 as well.

Thank you Kartikaya !!

So when it will be fixed, the editor behaviour will be the same before and after you switch to visual/code mode? I ask this because I have another problem with the editor acting differently after I click on "code" two times (the first time to get the BB code, the second time to get back to the visual mode). Should I open another ticket for this or can I report it here?

Thank you again :)

(In reply to matteo.sindona from comment #16)

So when it will be fixed, the editor behaviour will be the same before and after you switch to visual/code mode? I ask this because I have another problem with the editor acting differently after I click on "code" two times (the first time to get the BB code, the second time to get back to the visual mode). Should I open another ticket for this or can I report it here?

Assuming this is a different problem than what you described in comment 10, can you describe what the issue is? It might have the same underlying problem and might be taken care of by the fix for this ticket. If not I can always spin it out into another ticket.

Also for reference, this call site is the one getting hit by the drag-selection codepath and reading the "stuck" pending visual viewport offset.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #17)

(In reply to matteo.sindona from comment #16)

So when it will be fixed, the editor behaviour will be the same before and after you switch to visual/code mode? I ask this because I have another problem with the editor acting differently after I click on "code" two times (the first time to get the BB code, the second time to get back to the visual mode). Should I open another ticket for this or can I report it here?

Assuming this is a different problem than what you described in comment 10, can you describe what the issue is? It might have the same underlying problem and might be taken care of by the fix for this ticket. If not I can always spin it out into another ticket.

Hello Kartikaya, here is the steps to reproduce the problem I mean:

  1. login https://results.totallympics.com/
    Username: test
    Password: test

  2. Go here: https://results.totallympics.com/forum.php?mod=post&action=newthread&fid=71

  3. Copy a table from any site (for example this one: https://dataride.uci.ch/iframe/EventResults/209932?competitionId=59096&disciplineId=7); doesn't matter how you copy, you can either do it with mouse selection only or selecting cells with ctrl+mouse selection, you can copy part of the table or full table, it's the same.

  4. Paste it in the link of step 2.

  5. Click on one of the cells of the table (doesn't matter which one). Resizer of the table will now appear (see here: https://i.ibb.co/27ndVqM/September1.png). These buttons allow you to add or remove rows/columns or to change the width of the table

  6. Click "Advanced Mode" icon on the right end of toolbar if any (same as we did on step 6 of comment 10)

  7. Enable "Code" checkbox and then disable it (same as we did on step 7 of comment 10)

  8. Click on one of the cells again (doesn't matter which one)

  9. Resizer buttons now do not appear anymore

Note: this bug doesn't occur if you skip step 5: if you do not select any cell and you click on "Code" button, when you click on "Code" button again the resizers will appear.

Could you please let me know if this is happening to you as well and if you can fix this for the next Firefox releases ? Thank you!

I'm not able to reproduce this problem, the table resizers always appear for me. Can you perhaps take a video of the problem and post it here?

Hello Kartikaya,

you are right, if you do not write/delete anything the table resizers will always appear.
But if in step 7 you enable code and then you edit something in the BB code, then the table resizers will disappear when you will click on Code again: https://www.youtube.com/watch?v=fOLuUNAfp40&feature=youtu.be

I made another example. https://www.youtube.com/watch?v=dgajNu2Zixw&feature=youtu.be
Here the table resizer are still there when I just add something in the BB code of a row, but then they disappear when I delete something the second time I work with Code

One last example: https://youtu.be/e8Zlr2KoRJE
Here I add something in one row in the visual mode, go to code, go back to visual mode and table resizers are still there. Then without doing any other edit to the table, I click again on Code two times and table resizers disappear.

I am sorry I can not find a precise pattern of when this happens, but I hope with these 3 examples you can understand when and why it happens, and hopefully you can help me to fix this problem.

Thank you!

Thanks, but I still cannot reproduce this issue. I tried a bunch of different editing in both visual mode and code mode, but the resizers always show up when I click on a cell in visual mode. From the video also I'm not convinced the problem is the same, so I think it might be better to file another ticket for that one. Let me know if you'd like me to do that.

Component: DOM: Editor → Panning and Zooming

We set pending visual scroll updates even for RSFs that are on subdocuments,
so we should ensure they get acknowledged and cleared on paints. Otherwise
the pending visual scroll update can get "stuck" and it affects things that
depend on it, such as the drag-selection code.

The new promiseMouseDragEvent function is an async promise-returning copy of
the code in dragVerticalScrollbar. Eventually we should just make all this code
using async/promise but that's for another day.

Depends on D88893

Hello Kartikaya, I am going to open a new ticket for the table resizer problem.

As for this bug, you will let me know here when the problem will be solved ?

I will revert back to 79.0 version now because I need to use the editor a lot and right now is a nightmare, so I would like to know when I can download the latest version again. Thank you!

Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f83db4b41bf6
Acknowledge pending visual scroll updates for any RSF. r=botond
https://hg.mozilla.org/integration/autoland/rev/34ee0403ab1e
Add a test. r=botond

The wpt7 failure on Android seems to be rounding error, pretty much all the other subtests in that WPT are failing similarly. I'll just mark that one failing and file another bug for fixing that properly (with a meta-viewport tag).

The M3 windows failure seems like the wheel scroll of 100 pixels is only scrolling 85 pixels. I feel like I've run into this problem before, like it's rounding down to the nearest multiple of 17 pixels (1 line) so I'm just going to increase the scroll request and see if that fixes it.

Flags: needinfo?(kats)

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #30)

The M3 windows failure seems like the wheel scroll of 100 pixels is only scrolling 85 pixels. I feel like I've run into this problem before, like it's rounding down to the nearest multiple of 17 pixels (1 line) so I'm just going to increase the scroll request and see if that fixes it.

That doesn't work either, it seems. This would be a lot easier if I could just have APZ smooth-scroll to 0,0 with a scrollTo call but when I tried that it wasn't working properly because the request was getting clobbered by the frame reconstruction (something that should be fixed after bug 1662013 or one of its followups). But I'll see if I can fiddle with enough things to make that approach work.

I ended up just increasing the scroll delta enough to make the test pass on Windows. And filed bug 1662487 as a followup to fix it better.

Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3e764a5d3f97
Acknowledge pending visual scroll updates for any RSF. r=botond
https://hg.mozilla.org/integration/autoland/rev/4380b619b4b0
Add a test. r=botond

Hello Kartikaya, thank you for your work!!

So do you think in the next Firefox update this problem will be fixed ? Thank you again.

Once it makes it to mozilla-central it will go into the next Firefox nightly build (version 82). I'm also going to request uplift on the patches; if the release managers approve it will go into 81 beta and eventually 81 release.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 82 Branch

Comment on attachment 9173163 [details]
Bug 1661897 - Acknowledge pending visual scroll updates for any RSF. r?botond

Beta/Release Uplift Approval Request

  • User impact if declined: In some cases a page can get stuck in a weird state where trying to select text will scroll the content unexpectedly. The scenarios in which this occurs involve having an iframe that gets "reconstructed" (so the DOM element is hidden/readded) after being scrolled. Seems like a not-uncommon scenario with forum post editors.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Comment 6 and comment 8 have pretty clear STR
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The patch is pretty small and reasonably well-understood. The risk from this patch itself is low but there might be other similar scenarios that haven't been reported and still need to be fixed.
  • String changes made/needed:
Attachment #9173163 - Flags: approval-mozilla-beta?
Attachment #9173164 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9173163 [details]
Bug 1661897 - Acknowledge pending visual scroll updates for any RSF. r?botond

Approved for 81.0b6. Thanks for including a test.

Attachment #9173163 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9173164 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

Tested the issue on MacOS 10.14 and on two Windows 10 x64bit devices. The issue was reproduced on MacOS and the second Windows device, so can confirm it as verified fixed on latest Nightly 82.0a1 (20200903151816) and Beta 81.0b6 (20200903205131).

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
See Also: → 1664480
Duplicate of this bug: 1664480
You need to log in before you can comment on or make changes to this bug.