>>> My Info: Win7_64, Nightly 47, 32bit, ID 20160225030209 STR: 1. Set DPI -> 125% : Set that DPI level -> 125% in your OS [OR] Set layout.css.devPixelsPerPx -> 1.25 2. Launch new profile, enable Titlebar, enable Menu bar 3. Get screen with resolution 1366x768 [Steps 1-3 are only required to help you reproduce this. I can reproduce it w/o them] 4. Visit http://de.pons.com/, wait until it's fully loaded. 5. Click magnifier button in searchbar AR: Browser consumes 25% CPU and becomes very laggy ER: Browser should consume about 1-5% CPU and don't be laggy, like good old Firefox 28.0 This is regression. Good old Firefox 28 is unaffected, Firefox 47 with bad design is affected.

Bug 1113747 is about visual issue.

investigate with the see also bug to see root cause and potentially hand to graphics if the issue is there.

Any chance for a regression range slightly smaller than 28->47? If this is fairly recent, I wonder if bug 1256547 had a positive impact on it, and that landed in 47 on 4/21.

I can still reproduce the problem on Nightly49.0a1. https://hg.mozilla.org/mozilla-central/rev/77cead2cd20300623eea2416bc9bce4d5021df09 Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 ID:20160502030207 Regression window: https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=679466398b30&tochange=c9350d69c4bc Regressed: Bug 1088660

Narrowed down to a regression in Firefox 36. With this and bug 1238287 we have possibly useful STR. Florian, can you investigate or help find an owner for this bug? Unlikely we would fix this in 46 though.

Florian, I meant to n-i to you in comment 6.

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #6) > Narrowed down to a regression in Firefox 36. With this and bug 1238287 we > have possibly useful STR. Florian, can you investigate or help find an owner > for this bug? For me, this is still a duplicate of bug 1113747. Shell resolving as a duplicate in comment 1 was as a result of me voicing that opinion during a triage meeting. I saw comment 2, and while this bug is about the CPU load and the other one is about the visual problem, I don't think attempting to fix CPU usage for a completely broken and unintended display is worth anybody's time. If we want this fixed, we should ensure we display something that isn't broken; that's what bug 1113747 is about.

Thank you, I see now why you marked it as a duplicate. Why don't we connect it to bug 1113747 for now, and try to find someone to work on that bug.

Florian, this is a pretty bad regression, do you have time for it?

(In reply to Jim Mathies [:jimm] from comment #10) > Florian, this is a pretty bad regression, do you have time for it? Jim, this doesn't look like a regression to me (comment 5 shows the search panel has had that bug since the new searchbar UI has been introduced), and I'm also not sure why you say it's "pretty bad", given that it only happens in an edge case (using the searchbar while visiting a website that offers a massive number of open search plugins) that would hardly ever be encountered.

(In reply to Florian Quèze [:florian] [:flo] from comment #11) > Jim, this doesn't look like a regression to me (comment 5 shows the search > panel has had that bug since the new searchbar UI has been introduced), Exactly. When the buggy searchbar was introduced, it brought numerous regressions including this one. > it only happens in an edge case (using the searchbar while visiting a website that offers a > massive number of open search plugins) that would hardly ever be encountered. That's clearly not true, it also happens with a few search engines. You just haven't tested it at all. Why do you keep saying that completely broken UI (you intentinally regressed about a year ago) is OK?

Waiting on the results of bug 1113747.

We should fix this, but it's late in beta and I don't think we will block the release on it.

Tracked for Fx50, this seems like a core scenario.

(In reply to Florian Quèze [:florian] [:flo] from comment #11) > (In reply to Jim Mathies [:jimm] from comment #10) > > Florian, this is a pretty bad regression, do you have time for it? > > Jim, this doesn't look like a regression to me (comment 5 shows the search > panel has had that bug since the new searchbar UI has been introduced), and > I'm also not sure why you say it's "pretty bad", given that it only happens > in an edge case (using the searchbar while visiting a website that offers a > massive number of open search plugins) that would hardly ever be encountered. Do we have telemetry on how many open search plugins are offered on average? (In reply to arni2033 from comment #12) > (In reply to Florian Quèze [:florian] [:flo] from comment #11) > > Jim, this doesn't look like a regression to me (comment 5 shows the search > > panel has had that bug since the new searchbar UI has been introduced), > Exactly. When the buggy searchbar was introduced, it brought numerous > regressions including this one. > > > it only happens in an edge case (using the searchbar while visiting a website that offers a > > massive number of open search plugins) that would hardly ever be encountered. > That's clearly not true, it also happens with a few search engines. Do you have some examples that have fewer open search plugins that reproduce? FWIW, I can easily reproduce on de.pons.com.

Brindusa, can your team take a look at this as well please? Would be good to get a sense of whether there are other common sites where this is encountered.

(In reply to Andrew Overholt [:overholt] from comment #16) > (In reply to Florian Quèze [:florian] [:flo] from comment #11) > > (In reply to Jim Mathies [:jimm] from comment #10) > > > Florian, this is a pretty bad regression, do you have time for it? > > > > Jim, this doesn't look like a regression to me (comment 5 shows the search > > panel has had that bug since the new searchbar UI has been introduced), and > > I'm also not sure why you say it's "pretty bad", given that it only happens > > in an edge case (using the searchbar while visiting a website that offers a > > massive number of open search plugins) that would hardly ever be encountered. > > Do we have telemetry on how many open search plugins are offered on average? I don't think so. I don't know of any other website causing this.

Investigated this and could reproduce this on de.pons.com site on - Windows 7 64bit, Nightly 47.0a1, 32bit, Build ID 20160301030237 - Windows 10 64bit, Nightly 52.0a1, 32bit, Build ID 20160929030426 Unfortunately, I did not find any other similar sites.

(In reply to Andrew Overholt [:overholt] from comment #16) > Do you have some examples that have fewer open search plugins that reproduce? Sure, attachment 8706028 [details]. See "screencast 1" (In reply to Florian Queze [:florian] [:flo] from comment #18) > I don't think so. I don't know of any other website causing this. Websites causing this? On my default profile this can happen on many sites. Doesn't seem like a fault of website, as this bug manifested when the new searchbar (STILL broken in many ways) was introduced.

(In reply to arni2033 from comment #20) > Created attachment 8797590 [details] > screencast 1 - Searchbar causes 25% CPU consumption.webm This screencast is with the searchbar moved to the menu area. I suspect the excessive CPU usage in this case is due to the panel in panel situation, rather than to the open search providers listed.

(In reply to Florian Quèze [:florian] [:flo] from comment #21) > This screencast is with the searchbar moved to the menu area. I suspect the excessive CPU usage in > this case is due to the panel in panel situation, rather than to the open search providers listed. That's clearly not true, it also happens with searchbar on toolbar. You just haven't tested it at all. Why do you keep justifying that completely broken UI (you intentinally regressed about a year ago)?

We feel this bug shouldn't be tracked, since it's such a corner case, so I'm setting the status flags to reflect that. We are also waiting to see if the dependent bug fixes the problem here as well, in which case we will just resolve both at the same time. There is a new patch up there for review, so we should know soon enough.

50 is in RC mode, too late to fix this in 50

Now that bug 1113747 was fixed, someone who can reproduce needs to check in the next Nightly build whether this bug is fixed as well.

(In reply to Panos Astithas [:past] from comment #25) > Now that bug 1113747 was fixed, someone who can reproduce needs to check in > the next Nightly build whether this bug is fixed as well. Why do you even mention bug 1113747? It never blocked this bug, as it's a Core bug that became visible, because of new searchbar broken by Florian. Nobody ever explain why bug 1113747 could potentially fix it, everybody was just ignoring this bug and inventing excuses... And it is obvious =/ Even if you don't understand what the core issue is, from reading the patch in bug 1113747, and from the last screencast attached in this bug, it should be clear that bug 1113747 changed nothing Now all "blocking" bugs are resolved,so I need to know exact number of bug reports that you(team) will require to fix all aspects of this bug (possibly). I.e. what is this bug about. Are you(team) going to fix the core issue in this bug or change searchbar UI first? Please answer asap,then hide this comment Bugs caused by STR in comment 0 (please don't steal intentionally): 1) Core bug: XUL element that displays searchbar suggestions is designed to consume 25% cpu sometimes 2) Searchbar suggestions are so bad they trigger that "sometimes" part of Core bug (1) 3) Suggestions are so bad that sometimes I can't see more than 1-2 suggestions even if there's no (2)

(In reply to Panos Astithas [:past] from comment #25) > Now that bug 1113747 was fixed, someone who can reproduce needs to check in > the next Nightly build whether this bug is fixed as well. Tested this bug on Windows 7, with latest Nightly 53.0a1, Build ID 20170103030204 and CPU usage is 8-10%, never got to 25% CPU usage. Note that on Nightly 47, only a few times I succeed to get 25% CPU usage.

Thank you Brindusa, I will mark this as fixed then, most likely from bug 1113747.