Open Bug 1766136 Opened 2 years ago Updated 2 years ago

find search next freezes

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
Firefox 101
Platform:
Desktop
All
Type:
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:

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

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.

Component: Untriaged → Find Toolbar
Product: Firefox → Toolkit

I can reproduce the long freeze in Nightly101.0a1 Windows10.
https://share.firefox.dev/3vHhar0

Status: UNCONFIRMED → NEW
Component: Find Toolbar → Find Backend
Ever confirmed: true
OS: Unspecified → All
Product: Toolkit → Core
Hardware: Unspecified → Desktop
Keywords: hang
Flags: needinfo?(emilio)

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.

Flags: needinfo?(emilio) → needinfo?(zlice555)
  • Yes, a11y is activated by ATOK2021 Japanese IME Insight.
  • Disabling a11y (accessibility.force_disabled=1) seems to fix the freeze.

Reporter: Could you attach your about:support information?

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.

Flags: needinfo?(zlice555)

The severity field is not set for this bug.
:jfkthame, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jfkthame)

(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.

Component: Find Backend → Disability Access APIs
Flags: needinfo?(jfkthame)
Summary: find search next freezes → find search next freezes [with a11y enabled]

I think we might have two separate issues here:

  1. 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.
  2. 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.

: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).

Flags: needinfo?(jfkthame)
Component: Disability Access APIs → Layout
See Also: → 1745727
Summary: find search next freezes [with a11y enabled] → find search next freezes

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.

Flags: needinfo?(jfkthame)

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.

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.)

Flags: needinfo?(zlice555)

https://share.firefox.dev/3G4R322

empty/new profile freezing

Flags: needinfo?(zlice555)

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.

Flags: needinfo?(zlice555)

hm...it's empty. may try setting it to /dev/null or root only perms, getting rid of it ya

Flags: needinfo?(zlice555)

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

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.)

Flags: needinfo?(zlice555)

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.

Flags: needinfo?(zlice555)

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.

Severity: -- → S4

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

You need to log in before you can comment on or make changes to this bug.