Closed Bug 1421873 Opened 6 years ago Closed 6 years ago

Freeze after sending message in OX Mail due to AccessibleHandler text caching

Categories

(Core :: Disability Access APIs, defect)

All
Windows
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla59
Tracking Status
firefox-esr52 --- unaffected
firefox57 --- unaffected
firefox58 --- unaffected
firefox59 --- fixed

People

(Reporter: Jamie, Assigned: Jamie)

References

Details

(Keywords: regression)

Attachments

(1 file)

STR:
1. Open https://gold.ox.io/admin-api/tryme/user/gold/assignment
2. Log in to one of the provided accounts.
3. Select the Mail app.
4. Press Compose new email.
5. Write a message.
6. Send it.
Expected: No freeze.
Actual: After hitting the Send button, Firefox freezes with extremely high CPU load.

It seems HandlerProvider::GetAllTextInfoMainThread is infinitely stuck in the text attributes fetching loop. I haven't been able to isolate the exact cause yet. However, if you pass length as the offset, Gecko does return attributes for the last attribute run, even though length technically isn't included in that run. Also, if you pass an offset greater than the length, Gecko will return (0, 0). So, my guess is that the text is somehow mutating underneath us. This doesn't usually happen because we're blocking the main thread while we're doing this, but apparently, some calls can have side effects, probably related to layout computation.
Forgot to note I've seen this in Gmail on three separate occasions now, but I don't know of a reliable way to reproduce it there.
Blocks: 1419362
Keywords: regression
Alex, out of interest, could fetching text attributes actually cause the text in the node to change if there was some big CSS change? I'm imagining a case where getting attributes caused reflow and the browser realised some text needed to be hidden. This page lists a whole lot of stuff that causes layout/reflow and it does sound plausible that one of these might be happening:
https://gist.github.com/paulirish/5d52fb081b3570c81e3a
I've worked around this in HandlerProvider now (and it doesn't hurt to be safe), but I'm still curious as to why attribute runs would cease to exist after we fetch text but while we're still blocking the main thread.
Flags: needinfo?(surkov.alexander)
Comment on attachment 8933205 [details]
Bug 1421873: Fix infinite loop in HandlerProvider::GetAllTextInfoMainThread when invalid attribute offsets are returned.

https://reviewboard.mozilla.org/r/204150/#review209648
Attachment #8933205 - Flags: review?(mzehe) → review+
Pushed by mzehe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6f688725f9e7
Fix infinite loop in HandlerProvider::GetAllTextInfoMainThread when invalid attribute offsets are returned. r=MarcoZ
(In reply to James Teh [:Jamie] from comment #3)
> Alex, out of interest, could fetching text attributes actually cause the
> text in the node to change if there was some big CSS change?

not on a DOM level, but I believe the rendered text might change

> I'm imagining a
> case where getting attributes caused reflow and the browser realised some
> text needed to be hidden. This page lists a whole lot of stuff that causes
> layout/reflow and it does sound plausible that one of these might be
> happening:
> https://gist.github.com/paulirish/5d52fb081b3570c81e3a

sounds plausible

> I've worked around this in HandlerProvider now (and it doesn't hurt to be
> safe), but I'm still curious as to why attribute runs would cease to exist
> after we fetch text but while we're still blocking the main thread.

it might be connected to bug 1324042 by having same nature of things
Flags: needinfo?(surkov.alexander)
https://hg.mozilla.org/mozilla-central/rev/6f688725f9e7
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: