1318938 - Opening a new content process hangs GUI for several seconds since the build of 2016-11-19

Status: RESOLVED INCOMPLETE

(Core :: DOM: Content Processes, defect)

Description

[avada]

Since this build whenever a new content process is started the GUI hangs for several seconds. I see the main process at around the maximum 25% CPU usage.
I could reproduce this in safe mode. And even with one content process the hang is noticeable at startup.
Downgrading to the previous nightly build restores normal functioning.

However I couldn't reproduce it with a brand new profile.

Comment 1

[avada]

Attachment: about-support.txt

About:support from affected profile in safe mode.

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Could you try to using mozregression to find the actual patch that caused the problem?
https://harthur.github.io/mozregression/
That would be extremely helpful! There's an option to use an existing profile.

Comment 3

[avada]

(In reply to Bill McCloskey (:billm) from comment #2)
> Could you try to using mozregression to find the actual patch that caused
> the problem?
> https://harthur.github.io/mozregression/
> That would be extremely helpful! There's an option to use an existing
> profile.

No need. The day before it was good. I actually downgraded to 11-18 build, because it's excruciating to use FF like this, and the issue is gone.
So it's something that landed on the 2016-11-19 build.

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

(In reply to avada from comment #3)
> (In reply to Bill McCloskey (:billm) from comment #2)
> > Could you try to using mozregression to find the actual patch that caused
> > the problem?
> > https://harthur.github.io/mozregression/
> > That would be extremely helpful! There's an option to use an existing
> > profile.
> 
> No need. The day before it was good. I actually downgraded to 11-18 build,
> because it's excruciating to use FF like this, and the issue is gone.
> So it's something that landed on the 2016-11-19 build.

Mozregression is more precise than that though. It can bisect mozilla-inbound builds and tell us exactly which patch caused the regression. Otherwise we'll have to sift through a list of 100 or so patches that landed that day and try to figure out what might have caused it.

Comment 5

[avada]

(In reply to Bill McCloskey (:billm) from comment #4)
> Mozregression is more precise than that though. It can bisect
> mozilla-inbound builds and tell us exactly which patch caused the
> regression. Otherwise we'll have to sift through a list of 100 or so patches
> that landed that day and try to figure out what might have caused it.

How do I specify bits? I run x86, but mozregression defaults to x64. And the guide has no information on this.

Comment 6

[avada]

(In reply to Bill McCloskey (:billm) from comment #4)
Okay. Without a more detailed guide I won't be doing it. I can't set it to be the same build as I have. This with "hu" locale to be precise: https://archive.mozilla.org/pub/firefox/nightly/2016/11/2016-11-19-03-02-04-mozilla-central-l10n/


Also it starts with an empty profile which is useless, because the issue is not present with a fresh profile, and I couldn't successfully specify the profile I needed.

Comment 7

[Trevor Rowbotham [:rowbot]]

avada, you can find some documentation for mozregression at https://mozilla.github.io/mozregression/.  I think the page linked by :billm is outdated?

To run a specific profile using a 32 bit build, you might do something like the following:

mozregression --good 2016-11-18 --bad 2016-11-19 --profile /path/to/profile --bits 32

A full list of commands can be found by typing:

mozregression --help

Comment 8

[avada]

(In reply to Trevor Rowbotham from comment #7)
> avada, you can find some documentation for mozregression at
> https://mozilla.github.io/mozregression/.  I think the page linked by :billm
> is outdated?
> 
> To run a specific profile using a 32 bit build, you might do something like
> the following:
> 
> mozregression --good 2016-11-18 --bad 2016-11-19 --profile /path/to/profile
> --bits 32
> 
> A full list of commands can be found by typing:
> 
> mozregression --help

That didn't work for me on windows. When I pasted the full windows path, enter didn't run the command but opened a new line. When I changed backslashes to slashes it was just completely ignored. So all it accomplished is wasting my time. No idea what format it expects.

I'm expected find the bug for mozilla, but no-one bothers to maintain a valid, usable guide.

Comment 9

[avada]

Okay, so I figured it out. It claims it's bug 1151899:

13:04.82 INFO: Looks like the following bug has the changes which introduced the regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=1151899


(For the future, in case localization is a factor: How can I set mozregression to get builds that appear in the "latest-mozilla-central-l10n" section with a specific locale?)

Comment 10

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Thanks so much avada! It looks like that patch will be disabled. I know regression finding seems like a thankless task, but in this case it helped.

Unfortunately I don't think we localize mozilla-inbound builds, so it's not possible to get a localized version for regression finding.

Comment 11

[Gabor Krizsanits (INACTIVE)]

Is this still an issue or was it fixed by bug 1318432?

Comment 12

[avada]

Not sure. I disabled that rust thing as the preference was added. I'll have to check.

Comment 13

[avada]

Okay. So the issue is still present on my main profile. (network.standard-url.enable-rust;true)
Even in safe mode.

However on a new profile it isn't. No clue as to why. I guess there's another factor, a changed setting or something else.

Comment 14

[Florian Bender]

Can you try and run a diff on the settings files to see which ones are different? You/We can then work to figure it which pref is triggering this (if it is a pref at all).

Comment 15

[avada]

Lost interest. I won't be using v57 and this won't make it to v56. Plus all anyone ever did with it was getting me to jump through hoops.

Anyway I did a quick test (one last time) with network.standard-url.enable-rust;true. I couldn't reproduce it on beta, central won't even start with my main profile anymore, but it doesn't show the symptomps either with legacy extensions disabled or in safe mode.

So it may have been accidentally be fixed.