find search next freezes
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: zlice555, Unassigned)
References
Details
(Keywords: hang)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:101.0) Gecko/20100101 Firefox/101.0
Steps to reproduce:
- go to https://github.com/syoyo/tinygltf/blob/master/tiny_gltf.h
- ctrl+f (Highlight All selected)
- search for "buffer"
- next, next, next
Actual results:
search will eventually freeze, and by that time I already hit next a few times. By the time search catches up it spins through the page.
Expected results:
no lag searching through text
Firefox-Profiler file too big even as 7z. I can e-mail it.
Original creation of this silently failed - see https://bugzilla.mozilla.org/show_bug.cgi?id=1766134
Comment 2•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Toolkit::Find Toolbar' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 3•3 years ago
|
||
I can reproduce the long freeze in Nightly101.0a1 Windows10.
https://share.firefox.dev/3vHhar0
Updated•2 years ago
|
Comment 4•2 years ago
|
||
I can't quite reproduce this, https://share.firefox.dev/3MtRJjo is a profile of me just keeping enter pressed while going through the matches in that page.
From the profile in comment 3 it seems like something is rebuilding the whole layout tree, but I don't see that here. I can't see why either, because the profile starts too late.
Reporter:
- Mind attaching a link to the profile using the "upload local profile" button at the top right?
- Are you logged into GitHub, or does this reproduce logged out? Does it reproduce on a clean profile? (For the record I tried both logged in and out and I couldn't see this).
Alice:
- It seems most of the time is spent doing a11y work. Do you have accessibility enabled? Is perf better / does this reproduce at all with accessibility.force_disabled=1?
Thanks.
Comment 5•2 years ago
|
||
- Yes, a11y is activated by ATOK2021 Japanese IME Insight.
- Disabling a11y (accessibility.force_disabled=1) seems to fix the freeze.
Comment 6•2 years ago
|
||
Reporter: Could you attach your about:support information?
Comment 7•2 years ago
|
||
Rebuilding the whole layout tree
, I am not sure but it seems related to Bug 1605575.
https://share.firefox.dev/36Mg6tE
Holding enter helps speed things up.
Private window, no add-ons, not logged in.
Comment 9•2 years ago
|
||
The severity field is not set for this bug.
:jfkthame, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 10•2 years ago
|
||
(In reply to Alice0775 White from comment #5)
- Yes, a11y is activated by ATOK2021 Japanese IME Insight.
- Disabling a11y (accessibility.force_disabled=1) seems to fix the freeze.
It sounds like something in the a11y APIs may be behind this, then -- apparently triggering unwanted frame reconstruction? Moving to the a11y component for consideration.
Comment 11•2 years ago
|
||
I think we might have two separate issues here:
- In the profile from comment 3 (not the original reporter), a11y spends a lot of time in CoalesceEvents due to frame reconstruction. That sounds a lot like bug 1745727.
- In the profile from comment 8 (the original reporter), there are no a11y frames in the profile that I can see, suggesting this is not related to a11y.
If a lot of frame reconstruction is happening, a11y could certainly cause jank in response to that in some cases. However, I don't see how a11y could trigger frame reconstruction.
Comment 12•2 years ago
|
||
:jfkthame, thoughts on comment 11? Given that the original reporter isn't seeing a11y in the profile, should this be moved back to layout? We then have bug 1745727 for the a11y issue seen in the other profile (not from the reporter).
Updated•2 years ago
|
Comment 13•2 years ago
|
||
I guess if bug 1745727 will address the a11y issue, this can go back to layout. Though it's not clear to me that there's very much unusual in the comment 8 profile; I see a couple of somewhat slow reflows, but nothing really terrible.
At least one instance of jank in the profile in comment 8 looks like it's related to the system font list being updated, which is indeed quite expensive to handle (but I think it's reasonable to assume users are not usually making frequent changes to their installed font collection while using the browser). That's pretty much guaranteed to cause some jank because we have to not just re-create the list of available fonts via platform APIs, but then also reconstruct frames everywhere using the new font collection.
Reporter | ||
Comment 14•2 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=1758561
https://bugzilla.mozilla.org/show_bug.cgi?id=1751100
I'm starting to think these all have to be connected.
There are plenty of times where things seem like they just 'rebuild' and sometimes it is the GUI/GTK itself like menus or bookmarks and not just a single page.
Comment 15•2 years ago
|
||
A few notes, summing up what we've got here:
(A) @Alice0775's observations/profiles seem to be about an unrelated hang associated with a11y (which are covered by bug 1745727), per
comment 11.
(B) Original reporter (@zlice) shared a profile in comment 8 (here's that profile w/ just the github.com track, assuming that's the relevant track per this bug's STR: https://share.firefox.dev/3LyRzX6 ). But I don't think that profile actually captured the issue; it only seems to show two small back-to-back brief hangs (287ms and 85ms long, at the start and end of a 1-second period); and those seem to have been caused by the system font list being updated, as jfkthame observed in comment 13. Presumably that's not the actual cause of your original issue here, if you're not regularly installing/uninstalling fonts as you search GitHub. :) So I think that profile unfortunately seems not to demonstrate the real issue.
(C) Original reporter (@zlice) also linked two other bugs in comment 14; those bugs like they could be connected with each other (both are about popup menus in Firefox UI) but it doesn't seem clear that they'd be related to this bug here (which does not involve popups).
So. zlice, I have two requests for you:
-
For this bug here, could you capture and share another profile that demonstrates the issue? (Ideally in a fresh profile or with no other tabs open, to avoid background noise.) Note that (in response to your comment 1) you don't need to upload it as an attachment; you can just upload it and then share the permalink, as it looks like you discovered in comment 8.
-
For bug 1751100: it looks like that one is blocked on tracking down a regression range -- see Darkspirit's comment there with a command that you could use to help with that via
mozregression
. (That can follow up over there; for now I think it's best to assume this is a distinct issue.)
Updated•2 years ago
|
Reporter | ||
Comment 16•2 years ago
|
||
https://share.firefox.dev/3G4R322
empty/new profile freezing
Comment 17•2 years ago
|
||
At around the 15.6s time in that profile, it looks like something has happened that caused the system fontconfig library to refresh its set of currently-available fonts. This causes Firefox to rebuild its internal font lists and forces the reconstruction of frames/styles/etc (because the old ones might depend on fonts that have been changed/replaced).
What's not clear to me is why the fontconfig configuration has been updated. This reminds me of a recent discussion in https://matrix.to/#/#perf:mozilla.org where it turned out that the presence of a ~/.local/share/fonts/
directory for user-installed fonts was causing fontconfig to frequently refresh (even though the directory was empty!). So I'm curious: do you have a ~/.local/share/fonts/
directory? If so, try temporarily moving it away (so fontconfig won't try to use it) and see if that makes any difference to the issue you're seeing.
Reporter | ||
Comment 18•2 years ago
|
||
hm...it's empty. may try setting it to /dev/null or root only perms, getting rid of it ya
Reporter | ||
Comment 19•2 years ago
|
||
OMFG
i just had my bookmarks open for over a minute straight. rufkm?
holding 'enter' on a search/find is scrolling through the page consistently too!
idk where that directory came from but that seems to be it after a quick look.
hope it's not luck. ill keep an eye out definitely
Comment 20•2 years ago
|
||
Aha - interesting! So now I'm curious, what Linux distro are you using?
I wonder if this is caused by some kind of distro-specific configuration issue. (I have a local fonts dir like that on my Ubuntu machine, but have not been experiencing this problem. So I'd like to figure out what the key difference is.)
Reporter | ||
Comment 21•2 years ago
|
||
on void linux. asked some void people but didn't hear back so i assume there's nothing that comes to mind for anyone.
lsof | grep -i font
shows a few things running that have fonts open
ROX-Filer
conky
dunst
fluxbox
radeon-pr
urxvt
dunst did an update a bit back and radeon software may be doing something, everything else i've ran for ages.
do not see anything with lsof ~/.local/share/fonts
at all, even with firefox running and stalling on searching.
nothing running with font
or fc
in the name
weird indeed. just confirmed can search tiny_gltf code and browse bookmarks w/o dir.
Comment 22•2 years ago
|
||
Marking this as S4, as it appears to be caused by a fontconfig issue rather than really being a Firefox bug, though it would still be good to understand more fully why this is happening, and if there's something we could do to mitigate it.
Reporter | ||
Comment 23•2 years ago
|
||
Think this should be good to close per https://bugzilla.mozilla.org/show_bug.cgi?id=1758561
new fontconfig
doesn't seem to rebuild empty ~/.local/share/fonts
dir
Description
•