trying to View Source on twitter.com stalls out entire content process (spending lots of time in nsBidiPresUtils::TraverseFrames->nsBidiPresUtils::ResolveParagraph->SplitInlineAncestors)
Categories
(Core :: Layout: Text and Fonts, defect, P3)
Tracking
()
Performance Impact | low |
Tracking | Status | |
---|---|---|
firefox70 | --- | fix-optional |
firefox71 | --- | affected |
People
(Reporter: potch, Unassigned)
References
(Blocks 2 open bugs, )
Details
(Keywords: perf, Whiteboard: [sci-exclude])
Attachments
(2 files)
Updated•6 years ago
|
Comment 1•6 years ago
|
||
Comment 2•6 years ago
|
||
Comment 3•6 years ago
|
||
Updated•6 years ago
|
Comment 4•6 years ago
|
||
Updated•6 years ago
|
Comment 5•6 years ago
|
||
Updated•6 years ago
|
Comment 6•6 years ago
|
||
Comment 7•6 years ago
|
||
Comment 9•6 years ago
|
||
Updated•6 years ago
|
Comment 10•6 years ago
|
||
Comment 11•6 years ago
|
||
Comment 12•6 years ago
|
||
Comment 13•6 years ago
|
||
Updated•5 years ago
|
Comment 15•5 years ago
|
||
Tagging this for re-triage since it blocks the async-tab-switcher meta.
Updated•5 years ago
|
Comment 16•5 years ago
|
||
This came up in QF triage, and some folks couldn't reproduce, but I actually am still seeing several-second load times and reflows when view-sourc'ing the attached testcases (and the not-logged-in twitter.com front page), so I think this is still a valid bug.
[:darkspirit], why is this connected to async-tab-switcher? AFAICT, this is just one possible (and particularly-niche) way to trigger a slow reflow (and hang the content process in question. Is every "hang-the-content-process-for-a-bit" bug an async-tab-switcher blocker?
Comment 17•5 years ago
|
||
For reference (and just to have up-to-date data), here's a profile of me doing view-source on testcase 2 here: https://perfht.ml/2LMpYVM
Updated•5 years ago
|
Comment 18•5 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #16)
[:darkspirit], why is this connected to async-tab-switcher?
I don't know: https://bugzilla.mozilla.org/show_bug.cgi?id=1460123#a1173614_219124
Comment 19•5 years ago
|
||
Thanks, darkspirit.
dao, looks like this bug here is marked as blocking async-tab-switcher by virtue of you having marked bug 1460123 as blocking async-tab-switcher (below bug 1460123 comment 2), and then that bug later being duped to this one.
Do you still think it makes sense for these bugs to be tied to async-tab-switcher? Put another way: does it make sense for the async-tab-switcher metabug to depend on every bug that's filed for a content-process-hang that's long enough to manifest in a spinner on tab-switch, if the switched-to-tab happens to share the hung content process?
(My guess is "no" -- if the reason for a spinner is just that a background tab is temporarily hanging your content process, I don't think that's the fault of or related to async-tab-switcher... though I suppose it does manifest in the tab-switch operation taking longer to get to a usable state.)
Updated•5 years ago
|
Comment 20•5 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #19)
(My guess is "no" -- if the reason for a spinner is just that a background tab is temporarily hanging your content process, I don't think that's the fault of or related to async-tab-switcher... though I suppose it does manifest in the tab-switch operation taking longer to get to a usable state.)
👍
Updated•5 years ago
|
Updated•3 years ago
|
Updated•2 years ago
|
Description
•