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

Status: RESOLVED DUPLICATE of bug 1424709

(Core :: Widget: Cocoa, defect)

Description

[taebox]

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

Comment 1

[taebox]

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

Comment 2

[taebox]

Attachment: A screenshot of the Location sub-menu

Comment 3

[Emil Pasca [:emilpasca]]

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

Comment 4

[taebox]

Attachment: A better screenshot of the location menu.

Comment 5

[taebox]

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

Comment 6

[taebox]

Attachment: A screenshot of network settings to assist in creating new location profiles

Comment 7

[Flore Allemandou [:flore]]

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?

Comment 8

[Flore Allemandou [:flore]]

Looks like the high CPU could be a separate problem and is describe on bug 1425298

Comment 9

[taebox]

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

Comment 10

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

Comment 11

[Kershaw Chang [:kershaw]]

This should be a duplicate of bug 1424709.

Comment 12

[taebox]

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

Comment 13

[Kershaw Chang [:kershaw]]

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

Comment 14

[Stephen A Pohl [:spohl]]

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.

Comment 15

[Emil Pasca [:emilpasca]]

Moving this to same component for triage purpose, until bug 1424709 is fixed and this can be retested.

Comment 16

[taebox]

I do not get a repro anymore on nightly, 60.0a1 (2018-02-09) (64-bit)

Comment 17

[Stephen A Pohl [:spohl]]

Thanks for confirming!