1251977 - Searchbar causes 25% CPU consumption if I open suggestions (100% str)

Status: RESOLVED WORKSFORME

(Firefox :: Search, defect, P2)

Description

[arni2033]

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

Comment 2

[arni2033]

Bug 1113747 is about visual issue.

Comment 3

[:shell escalante]

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

Comment 4

[Milan Sreckovic [:milan] (needinfo for best results)]

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.

Comment 5

[Alice0775 White]

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

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

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

Comment 8

[Florian Quèze [:florian]]

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

Comment 9

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 10

[Jim Mathies [:jimm]]

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

Comment 11

[Florian Quèze [:florian]]

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

Comment 12

[arni2033]

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

Comment 13

[Jim Mathies [:jimm]]

Waiting on the results of bug 1113747.

Comment 14

[Liz Henry (:lizzard) (relman/hg->git project)]

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

Comment 15

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Tracked for Fx50, this seems like a core scenario.

Comment 16

[Andrew Overholt [:overholt]]

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

Comment 17

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 18

[Florian Quèze [:florian]]

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

Comment 19

[Brindusa Tot, Desktop QA]

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.

Comment 20

[arni2033]

Attachment: screencast 1 - Searchbar causes 25% CPU consumption.webm

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

Comment 21

[Florian Quèze [:florian]]

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

Comment 22

[arni2033]

(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)?

Comment 23

[Panos Astithas (he/him) [:past] (please ni?)]

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.

Comment 24

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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

Comment 25

[Panos Astithas (he/him) [:past] (please ni?)]

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.

Comment 26

[arni2033]

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

Comment 27

[Brindusa Tot, Desktop QA]

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

Comment 28

[Panos Astithas (he/him) [:past] (please ni?)]

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