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)
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.
Assignee | ||
Comment 1•6 years ago
|
||
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
Comment hidden (mozreview-request) |
Assignee | ||
Comment 3•6 years ago
|
||
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 4•6 years ago
|
||
mozreview-review |
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
Comment 6•6 years ago
|
||
(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)
Comment 7•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/6f688725f9e7
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox59:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Updated•6 years ago
|
status-firefox57:
--- → unaffected
status-firefox58:
--- → unaffected
status-firefox-esr52:
--- → unaffected
You need to log in
before you can comment on or make changes to this bug.
Description
•