Closed Bug 1423273 Opened 3 years ago Closed 3 years ago

On Mac OS X Sierra, using the Apple > Location menu creates a new Firefox process that hangs at high cpu

Categories

(Core :: Widget: Cocoa, defect)

57 Branch
x86_64
macOS
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1424709

People

(Reporter: taebox, Unassigned)

Details

(Keywords: hang)

Attachments

(3 files, 1 obsolete file)

Attached file Sample of firefox.txt
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171128222554

Steps to reproduce:

With a Firefox window in focus:
Click the Apple > Location > [choose any location]


Actual results:

It actually does nothing (seemingly)
and a Firefox process is spun up which subsequently uses a lot of cpu


Expected results:

Location should change (network configuration profile)
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86_64
Application Basics
------------------

Name: Firefox
Version: 57.0.1
Build ID: 20171128222554
Update Channel: release
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0
OS: Darwin 16.7.0
Multiprocess Windows: 2/2 (Enabled by default)
Web Content Processes: 4/4
Stylo: true (enabled by default)
Google Key: Found
Mozilla Location Service Key: Found
Safe Mode: false
Attached image A screenshot of the Location sub-menu (obsolete) —
Severity: normal → critical
Keywords: hang
I have tried to test this issue, however, I could not find the "Apple > Location > [choose any location]" menu item on different MacBook Pro or iMac stations with OS 10.12.

Could you please specify if you are using any application or customization settings which we could also install on our machines in order to enable the option in the Apple menu?

Also in the meantime I would kindly ask you to retest this using the latest Nightly build (https://nightly.mozilla.org/)? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/AR5o9d).
Flags: needinfo?(taebox)
Attachment #8934626 - Attachment is obsolete: true
I wasn't able to test on the latest nightly as it's crashing before the UI even shows up. I did however test on a brand new clean profile and I was able to reproduce the problem. I uploaded a better screenshot of the Location menu. If you don't find location menu on your system you may need to create a profile first under network settings.

Apple > System Preferences > Network > [Location drop-down] > Edit locations...
Flags: needinfo?(taebox)
Interesting thing, I created a location (as said on comment 5). I now see the location menu (Configuration réseau in french, my locale).
I tested with an old nightly (last week) and could reproduce the "does nothing" part but not the spinning wheel. When using other non-mozilla apps, it works (changes the location), but it does not work either with thunderbird.

I updated to latest nightly (20171218100313) and the change of network no works. (still does not work with Thunderbird and still works with other apps, those are my control). But I never observed the high CPU usage you describe. Might be another problem

Can you check with the latest nightly if the change of location works?
Flags: needinfo?(taebox)
Looks like the high CPU could be a separate problem and is describe on bug 1425298
(In reply to Flore Allemandou [:flore] from comment #8)
> Looks like the high CPU could be a separate problem and is describe on bug
> 1425298

Bug 1425298 is a duplicate, this is the same issue.
Flags: needinfo?(taebox)
The hallmark of this issue is that a new `firefox` process is spawned and it uses very high cpu. In addition, as stated in bug 1425298, you have to force-kill the new process and doing so has no effect on the Firefox UX. Bug 1425298 doesn't mention, but I am reasonably sure it is the case, that the location change that was requested doesn't happen.
This should be a duplicate of bug 1424709.
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1424709
(In reply to Kershaw Chang [:kershaw] from comment #11)
> This should be a duplicate of bug 1424709.

I disagree for two reasons. Firstly, my report doesn't involve any crashing, it involves a process hanging. Secondly, if anything, bug 1424709 is a duplicate of this bug because 1424709 is newer. (this may be my SDET showing)
While the fix to bug 1424709 may also fix the issue I am having, I still believe it should be tracked separately.
Flags: needinfo?(kechang)
(In reply to taebox from comment #12)
> (In reply to Kershaw Chang [:kershaw] from comment #11)
> > This should be a duplicate of bug 1424709.
> 
> I disagree for two reasons. Firstly, my report doesn't involve any crashing,
> it involves a process hanging. Secondly, if anything, bug 1424709 is a
> duplicate of this bug because 1424709 is newer. (this may be my SDET showing)
> While the fix to bug 1424709 may also fix the issue I am having, I still
> believe it should be tracked separately.

I am not 100% sure, but I still think this is a duplicate of bug 1424709.
:spohl, what do you think?

Thanks.
Flags: needinfo?(kechang) → needinfo?(spohl.mozilla.bugs)
Let's keep this bug open until we have a fix for bug 1424709 and we're able to confirm that it fixes this issue as well.
Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: needinfo?(spohl.mozilla.bugs)
Resolution: DUPLICATE → ---
Moving this to same component for triage purpose, until bug 1424709 is fixed and this can be retested.
Component: Untriaged → Widget: Cocoa
Product: Firefox → Core
I do not get a repro anymore on nightly, 60.0a1 (2018-02-09) (64-bit)
Thanks for confirming!
Status: REOPENED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1424709
You need to log in before you can comment on or make changes to this bug.