1489785 - [MacOS 10.14] Cannot choose where to download files or print because popup window always freeze

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect, P1)

Description

[gen.moz]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180830143136

Steps to reproduce:

OS: MacOS Mojave 10.14

Problem: Cannot choose where to download, print, or browse files because popup window always freeze

Scenario 1:
- In Settings > General > Files and Application > Downloads. Check "Always ask you where you save files"
- Go to a random site, right click and select "Save Page As...". - The file explorer window appears. It freezes within 30 seconds, or even instantly

Scenario 2:
- Go to a random site. In Menu bar, File > Print
- The print window appears. It freezes within 30 seconds, or even instantly

Scenario 3:
- In Menu bar, File > Open File
- The file explorer window appears. It freezes within 30 seconds, or even instantly

Troubleshooting:
- The only way to solve the problem is to force close Firefox process from Activity Monitor.
- The issue persists in safe mode
- The issue persists when I refresh Firefox
- The issue persists when I uninstall/reinstall Firefox


Actual results:

Popup windows (for download, print, open files, browse files...) always freeze when they appear.


Expected results:

Popup windows (for download, print, open files, browse files...) should work fine without freezing

Comment 1

[Marcia Knous [:marcia]]

Hello gen.moz - Your bug sounds a lot like Bug 1466987. Which version of 10.14 are you running?

Comment 2

[gen.moz]

Hi Marcia. I am running 10.14 Beta 9 (18A384a). The issue existed in previous Betas but I did not report the bug until now. 

I read Bug 1466987 too. However, my laptop did not freeze, only Firefox app. I can still move the popup window around, but I could not click anything on the window (OK, Cancel, navigate folders, etc)

Hardware: Macbook Pro 15" 2016 (Intel i7, 16GB RAM, AMD Radeon Pro 455)
https://everymac.com/systems/apple/macbook_pro/specs/macbook-pro-core-i7-2.7-15-late-2016-retina-display-touch-bar-specs.html

Let me know if there is anything else I can do to help triage this issue.

Comment 3

[Marcia Knous [:marcia]]

Hello Camelia - Can you try reproducing this on your 10.14 machine and report back the results? My machine is a bit different than the reporter's - MacBook Pro (13-inch, 2017, Four Thunderbolt 3 Ports), 3.5 GHz Intel Core i7, 16 GB 2133 MHz LPDDR3, Intel Iris Plus Graphics 650 1536 MB.

gen.moz: Does this just happen in 62, or with all versions of Firefox (Nightly, 63 beta, etc?)

Comment 4

[gen.moz]

Hi Marcia. I tested just now. It also happens on Beta 63.0b5 and Nightly 64.0a1.

Comment 5

[Marcia Knous [:marcia]]

Hello gen.moz - Apple just pushed another beta, beta 11. Can you kindly test with that version and report back if the issue still reproduces? Thanks!

Comment 6

[gen.moz]

I am using Public Beta 10 (18A384a) which just got released today. I do not have Developer Beta. Unfortunately, the problem still persists here. When newer updates of Mojave comes, I will retry the steps and let you know.

I will also be using exclusively Firefox Nightly now. Firefox Nightly is causing conflicts with regular Firefox app for me. Regular Firefox now crashes every launch so I just uninstall it.

Comment 7

[Camelia Badau [:cbadau], Desktop Test Engineering]

I can't reproduce the issue; I tried all the scenarios from Description, but without success.I tested on macOS 10.14 Beta build 18A384a and build 18A389 (beta 11) using Firefox 62, latest Nightly 64.0a1 (2018-09-12) and Firefox 63.0b5. 

Hardware:
- MacBook Pro (Retina, 15-inch, Late 2013) - Intel Iris Pro 1536MB
- iMac (21.5-inch, Late 2012) - NVIDIA GeForce GT 640M 512MB

Ovidiu, can you please see if you can reproduce this issue?

Comment 8

[ovidiu boca[:Ovidiu]]

I was able to reproduce this issue on Mac OS X 10.14 beta build 18A389 (beta 11) using FF 62 release and FF Nightly 64.0a1(2018-09-12) and Nightly 64.0a1(2018-09-13)

I have a MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports) 2,3 GHz Intel Core i5, 8Gb memory and Intel Iris Plus Graphics 640  1536MB
 

What I noticed is that you don't need to do the setting from "Preferences", you just need to press right click on a page -> select "Save Page As" and click on the text field from "Save As", the browser freezes.

Comment 9

[Marcia Knous [:marcia]]

So it seems like from the latest comments it is only reproducible on some kinds of hardware. 

Reproducible:

Reporter has: Hardware: Macbook Pro 15" 2016 (Intel i7, 16GB RAM, AMD Radeon Pro 455)
Ovidiu has: MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports) 2,3 GHz Intel Core i5, 8Gb memory and Intel Iris Plus Graphics 640  1536MB

Not reproducible:

marcia's MBP: MacBook Pro (13-inch, 2017, Four Thunderbolt 3 Ports), 3.5 GHz Intel Core i7, 16 GB 2133 MHz LPDDR3, Intel Iris Plus Graphics 650 1536 MB.

Camelia's Hardware:
- MacBook Pro (Retina, 15-inch, Late 2013) - Intel Iris Pro 1536MB
- iMac (21.5-inch, Late 2012) - NVIDIA GeForce GT 640M 512MB

Interesting that my machine is fairly similar to Ovidiu's but I cannot reproduce it on nightly or beta.

Comment 10

[Marcia Knous [:marcia]]

Markus: Any ideas here? Would it be prudent to get a bug on file with the Apple Bug reporter if we think it is something on their side?

Comment 11

[Markus Stange [:mstange]]

The open / save dialogs seems to break frequently in the Betas of every major macOS update, don't they?
Yes, I think this is worth filing with Apple.

Comment 12

[Marcia Knous [:marcia]]

(In reply to Markus Stange [:mstange] from comment #11)
> The open / save dialogs seems to break frequently in the Betas of every
> major macOS update, don't they?
> Yes, I think this is worth filing with Apple.

Yes, they do. I guess in this case it is not happening consistently across all installations. Earlier we had Bug 1466987, but for me that was freezing the entire OS, not just Firefox.

Comment 13

[Marcia Knous [:marcia]]

I filed 44417911 issue for this in the Apple Bug Reporter.

Comment 14

[Marcia Knous [:marcia]]

(In reply to Marcia Knous [:marcia - needinfo? me] from comment #13)
> I filed 44417911 issue for this in the Apple Bug Reporter.

I was asked for the following information in the bug - Ovidiu can you help?:

-- sysdiagnose Instructions:

https://developer.apple.com/services-account/download?path=/OS_X/OS_X_Logs/sysdiagnose_Logging_Instructions.pdf


-- System Information Report instructions:

To obtain a full System Information Report (also known as ASP, system profile, spx, system configuration):

1. Select 'About This Mac' from the Apple Menu
2. Click the “System Report” button on the About This Mac window
3. Select 'Save…' from the File menu (cmd-s)
4. Change the file name and save location as needed
5. Click the 'Save' button

A System Information Report can also be obtained via Terminal using the following command:

/usr/sbin/system_profiler -detailLevel full -xml > ~/Desktop/mymachine.spx

This command will create a full System Information Report, named 'mymachine.spx', which will open on another machine.

Comment 15

[ovidiu boca[:Ovidiu]]

Attachment: MacBook Pro.spx

Thanks Marcia for all the details, I've attached the System Information Report in  the bug report and also the sysdiagnose Instructions can be found here: https://transfernow.net/915qr922j08n

Please let me know if there is anything else that I can do.

Comment 16

[Marcia Knous [:marcia]]

Ovidiu: Here are the comments back from the bug report - Apple developers haven't been able to reproduce it:

To look into this further we will need a sysdiagnose taken while Firefox is hanging in this state. A screen capture of the steps to get Firefox into this state would also be helpful.

Please provide your response or results by updating your bug report.  If uploading files, please compress first.

Comment 17

[ovidiu boca[:Ovidiu]]

Hi, 

I reproduce it again and here is the screen recording: https://streamable.com/07988

Also here is the sysdiagnose, it's compressed. 

https://drive.google.com/file/d/1s-g-IFvS8OIkhLPgyjBvkcTpGQRifR3B/view?usp=sharing

Please let me know if there is any other information that I can provide.

Comment 22

[Sylvestre Ledru [:Sylvestre]]

Release Note Request (optional, but appreciated)
[Why is this notable]: Regression with the last version of Mac Os X
[Suggested wording]: "File management can fail on Mac OS X 10.14 Mojave"
[Links (documentation, blog post, etc)]:

Comment 23

[[:philipp]]

the problem also gets reported on our support channels after the release of the osx update yesterday:
https://support.mozilla.org/en-US/questions/firefox?owner=all&tagged=bug1489785&show=all

Comment 24

[Julien Cristau [:jcristau]]

Added to 62 relnotes as a known issue.

Comment 25

[Marcia Knous [:marcia]]

(In reply to ovidiu boca[:Ovidiu] from comment #17)
> Hi, 
> 
> I reproduce it again and here is the screen recording:
> https://streamable.com/07988
> 
> Also here is the sysdiagnose, it's compressed. 
> 
> https://drive.google.com/file/d/1s-g-IFvS8OIkhLPgyjBvkcTpGQRifR3B/
> view?usp=sharing
> 
> Please let me know if there is any other information that I can provide.

Can you reproduce it on the version released yesterday,18A391?

Comment 26

[Marcia Knous [:marcia]]

(In reply to Marcia Knous [:marcia - needinfo? me] from comment #13)
> I filed 44417911 issue for this in the Apple Bug Reporter.

I haven't heard anything back from Apple since Comment 16. Apple has all the information they requested we provide.

Comment 28

[brandon.dusseau]

I am able to reproduce this issue on 10.14 build 18A391. I am using the following hardware:

MacBook Pro 2018 15", i7-8850H 2.60 GHz, 32 GB RAM, AMD Radeon Pro 560X

When saving any image file (at least, I haven't tested other types yet) from any web page using the Save As dialog, the dialog becomes unresponsive after a short interval (enough for me to navigate through directories but not enough to even begin entering a filename). Both the file browser dialog and the Firefox window remain draggable but are otherwise unresponsive. When the freeze occurs, Firefox's CPU usage maxes out one of my cores. I have to force quit the application to close it.

I am unable to reproduce the issue with other software using the same Save As UI widget (i.e. Chrome).

My steps to reproduce:
 1. Right click an image on a web page
 2. Select "Save As..."
 3. Attempt to navigate to a directory
 4. Select the filename field - it is unresponsive

Comment 29

[brandon.dusseau]

Update to my comment above - it affects all file dialogs on my machine, including open file dialogs, as I found when I tried to change my avatar on here. Based on the release note added, I suspect you already know this, though.

Comment 30

[Julien Cristau [:jcristau]]

Going to track this for 62.  This is gathering lots of dupes now 10.14 is out.

Stephen, is this something you can look into?

Comment 31

[ovidiu boca[:Ovidiu]]

I'm able to reproduce this issue, with MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports) OS 10.14 (18A391) on the latest Nightly 64.0a1(2018-09-25).

Comment 32

[Stephen A Pohl [:spohl]]

Updating my system and looking into it. Keeping n-i set.

Comment 34

[francescotacconi]

I have this issue on iMac Pro 2017, Intel Xeon W, 3,2GHz, 8 Core, 32 GB memory and Mac OsX Mojave 10.14 official release on Firefox 62.0.2 (64bit).

Comment 35

[Jason Frisvold]

I have this issue on my Macbook Pro 15" Mid 2015, 2.8 Ghz Intel Core i7, 16 GB RAM.  I'm currently running 10.14.1 Beta 1 and using Firefox 62.0.2 (64-bit).

I've been seeing this same behavior since the first Mojave beta and it persists into the first beta patch as well.  Happy to provide whatever info I can to get this resolved.

Comment 37

[Stephen A Pohl [:spohl]]

Able to reproduce. Looking into it.

Comment 38

[Sveon]

I have this issue as well. Nightly on MacBook Pro (Retina, 13-inch, Late 2013)

However, this appears to be the fault of macOS. I have the same problem with Safari, Chrome Beta and Opera Developer. Even in Preview if I try to export a screenshot (let's say from PNG to JPG) the file dialog freezes for a few seconds.

Comment 39

[Stephen A Pohl [:spohl]]

Does the dialog recover after a few seconds for you? Does it recover for Firefox, Safari and Chrome?

Comment 40

[Sveon]

Yes. If I try to upload a file (for example, attach a file to a Gmail message), I notice the following scenarios:

SCENARIO 1 (freezes before selection)

1. When I click the "browse" button, it freezes for a few seconds (usually at least 10 seconds)
2. Then I can select a file
3. Then the dialog closes and returns to the site and I can use the browser normally again

OR

SCENARIO 2 (freezes after selection)

1. When I click the "browse" button, the file dialog opens immediately
2. I can select a file
3. When I press the "open" button it freezes for at least 10-15 seconds (spinning beachball)

When the freezes occur I cannot use the browser, but other apps work fine. I've seen this in every browser I have installed.

Comment 41

[brandon.dusseau]

This sounds different from what I am experiencing. For me, the dialog never recovers but does not beachball. I do tend to have at least a couple seconds to make selections before it freezes. For me, it affects Firefox only.

Comment 42

[Jason Frisvold]

I'm seeing the same as @brandon.dusseau.  There is no beachball or other indication that the dialog has frozen beyond the inability to interact with the dialog itself.  I can move the dialog window using the normal click and drag.  Additionally, if you right click on the Firefox icon in the dock, the dialog shows "Quit" and not "Force Quit" as one typically sees when the system recognizes that a program has stopped responding.

As Brandon suggests, I can often interact with the file dialog for a few moments, sometimes able to change to a different folder, but, more often than not, the dialog will end up freezing.  This happens when saving a file or web page, as well as when trying to upload something to a website and the dialog appears to pick the file to upload.

I have previously seen behavior similar to that of @Sveon when running early Mojave betas, but that behavior went away somewhere around Beta 9 or 10.

Comment 43

[mail.stephan.bender]

same here on 2 Macs running the official Moja release and the latest versions of Firefox and Thunderbird.
Yes: it's also affecting the Thunderbird "Open file" dialog when trying to attach a file to a mail.

Comment 44

[smsapiro]

Also experiencing this issue on my MacBook Pro Retina 15in Mid 2015 2.8 GHz i7, macOS Mojave 10.14

It's good to know I'm not alone. For me, the issue will also occur immediately after clicking on a text field in any of the menus (eg. the print menu). Happy to help in any way, please let me know.

Comment 45

[Sylvestre Ledru [:Sylvestre]]

Stephen, fyi, if we have a patch, we would take it in the next dot release (probably next week).

Comment 46

[Zak]

(In reply to Stephen A Pohl [:spohl] from comment #39)
> Does the dialog recover after a few seconds for you? Does it recover for
> Firefox, Safari and Chrome?

I only get crashes on FF.  Chrome and Safari never have the issue, and I've tried to nav around the dialog for a while (long after it would have crashed on FF).  

Macbook Pro 15" Mid 2018, 2.6 Ghz Intel Core i7, 16 GB RAM.  I'm currently running 10.14 (dev beta 10) and using Firefox 62.0.2 (64-bit).

Comment 47

[Sorin Sbarnea]

Mojave was already released and this critical bug is still present making close to impossible to use Firefox.

Can I do anything to help digging this bug, it seems extremely easy to reproduce: try to upload file and try to change folder (if it doesn't get stuck before that).

Comment 48

[Stephen A Pohl [:spohl]]

Thanks all. I'm able to reproduce and am looking into it.

Comment 49

[martinky24]

This bug is pushing more and more of my day-to-day tasks to Chrome.

(macOS 10.14, 2018 MacBook Pro, Firefox 62.0.2)

Comment 51

[Stephen A Pohl [:spohl]]

Attachment: Patch

This removes a workaround that prevented a crash during history swiping (bug 678607). From reading the bug comments, the workaround seemed to address an issue in gcc.

We will need to make sure that the crash during history swiping (bug 678607) doesn't reappear on all versions of macOS. I have tested the patch on macOS 10.14: modal dialogs work as expected and I have not been able to reproduce the crash in bug 678607.

Try push coming up. I will post the direct link to the try build as soon as it is available for everyone to verify the fix.

(Ironic side-note: this bug prevented me from uploading the patch to bugzilla on 10.14 until I was fast enough to not encounter the hang in the upload dialog. Not being able to upload code to fix a bug due to that very bug is definitely a first.)

Comment 52

[Markus Stange [:mstange]]

Comment on attachment 9013125 [details] [diff] [review]
Patch

Good find. And also rather unfortunate that it ended up being our fault after all :(
It would probably be worth going through the entire widget/cocoa code and auditing all of these types of workarounds.

Comment 53

[Stephen A Pohl [:spohl]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d13396e1cab130207b5d4c019db7c2c505ea8162

Comment 54

[Jason Frisvold]

(In reply to Stephen A Pohl [:spohl] from comment #51)
> (Ironic side-note: this bug prevented me from uploading the patch to
> bugzilla on 10.14 until I was fast enough to not encounter the hang in the
> upload dialog. Not being able to upload code to fix a bug due to that very
> bug is definitely a first.)

!!!

Awesome work identifying the issue and putting together a patch so quickly.  Looking forward to seeing this bug go away!

Comment 55

[Zak]

This is great to hear, and thank you Stephen and all that build Mozilla. 

Does anyone know how long changes take to build into nightlies?

Comment 56

[Stephen A Pohl [:spohl]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3920c858319dff66ebbc9263f6aa8d24f16071f8
Bug 1489785: Remove a workaround for gcc, introduced in bug 678607, that is no longer needed and that causes hangs in modal dialogs on macOS 10.14. r=mstange

Comment 57

[Stephen A Pohl [:spohl]]

(In reply to Stephen A Pohl [:spohl] from comment #51)
> Try push coming up. I will post the direct link to the try build as soon as
> it is available for everyone to verify the fix.

The try build is now available here:

https://queue.taskcluster.net/v1/task/ePCqVygLRamqhpztF5-nHQ/runs/0/artifacts/public/build/target.dmg

It would be great to get confirmation from some of you that the hang is indeed fixed in this build.

(In reply to Zak from comment #55)
> This is great to hear, and thank you Stephen and all that build Mozilla. 
> 
> Does anyone know how long changes take to build into nightlies?

The patch just landed on inbound and will either appear in today's (9/30) or tomorrow's nightly.

Comment 58

[Stephen A Pohl [:spohl]]

Ovidiu, would you be able to test the fix for the hang and also confirm on all versions of macOS that we're not encountering the crash that was reported in bug 678607? Or does this need to be a more formal request? Per comment 45, there is a desire to include this in the next dot release (which I fully support). Thanks!

Comment 59

[Zak]

I have been saving images out of it for the past 15 min or so.  Lots of long-duration traversal of the folder structure via the file dialog.  No problems happened ever. 

I am switching to this nightly build until these changes are merged to the mainline.

Macbook Pro 15" Mid 2018, 2.6 Ghz Intel Core i7, 16 GB RAM.  I'm currently running 10.14 (dev beta 10) and using the nightly that Stephen Pohl linked in comment 57.

Thank you!

Comment 60

[mail.stephan.bender]

Hi, great to read a solution is in sight.
Will this also fix the corresponding Thunderbird bug (see my comment #43)?
Or do I have to file a separate bug report for thunderbird?

Comment 61

[Stephen A Pohl [:spohl]]

(In reply to mail.stephan.bender from comment #60)
> Hi, great to read a solution is in sight.
> Will this also fix the corresponding Thunderbird bug (see my comment #43)?
> Or do I have to file a separate bug report for thunderbird?

The patch will have to be ported to the Thunderbird repo. A new bug for this would be great. Thanks!

Comment 62

[uzairktk]

Thank you for the quick fix. I have tested the issue on the nightly fix and it seems to work OK. 

MacBook Pro (13-inch, 2016, Two Thunderbolt 3 ports w/o touchbar) running Mojave 10.14 (18A391).

Comment 63

[Frank-Rainer Grahl (:frg)]

> The patch will have to be ported to the Thunderbird repo. A new bug for this would be great.

It just needs ESR60 approval and will then be picked up.

Jorg, check this one. Might need to go in fast for the next release.

Comment 64

[Jorg K (CEST = GMT+2)]

Thanks.

Comment 65

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/3920c858319d

Comment 66

[mail.stephan.bender]

(In reply to Frank-Rainer Grahl (:frg) from comment #63)
> > The patch will have to be ported to the Thunderbird repo. A new bug for this would be great.
> 
> It just needs ESR60 approval and will then be picked up.
> 
> Jorg, check this one. Might need to go in fast for the next release.

Hi,
I am not familiar with those mechanisms. Do I still need to write a new bug report for the Thunderbird App?
For me, Thunderbird part of this bug is more severe than the "Firefox side", so I would be very thankful for a fast solution...
Thank you!

Comment 67

[Stephen A Pohl [:spohl]]

(In reply to mail.stephan.bender from comment #66)
> (In reply to Frank-Rainer Grahl (:frg) from comment #63)
> > > The patch will have to be ported to the Thunderbird repo. A new bug for this would be great.
> > 
> > It just needs ESR60 approval and will then be picked up.
> > 
> > Jorg, check this one. Might need to go in fast for the next release.
> 
> Hi,
> I am not familiar with those mechanisms. Do I still need to write a new bug
> report for the Thunderbird App?
> For me, Thunderbird part of this bug is more severe than the "Firefox side",
> so I would be very thankful for a fast solution...
> Thank you!

No, this means that this will "automagically" be taken care of by our friends on the Thunderbird side and there isn't even a need for a separate bug. :-) Thanks for offering to help though.

Comment 68

[francescotacconi]

Hi
Maybe I don't have understood.
The bug is fixed on Firefox Nightly, but I use Firefox Quantum, what do I have to do?
Thank you

Comment 69

[Sylvestre Ledru [:Sylvestre]]

Stephen, could you please fill the uplift requests to Beta, release and esr ?
Thanks

Comment 70

[Jorg K (CEST = GMT+2)]

https://hg.mozilla.org/releases/mozilla-esr60/rev/8d71faee5dcdd0773b7e0830b8fad96a6bda559b (THUNDERBIRD_60_VERBRANCH) for TB 60.2.1.

Comment 71

[Jorg K (CEST = GMT+2)]

Mac users can try this build of TB 60.2.1:
https://queue.taskcluster.net/v1/task/eVoGiTzYTSmBYEeIsgo-pw/runs/0/artifacts/public/build/target.dmg

Comment 72

[Stephen A Pohl [:spohl]]

Comment on attachment 9013125 [details] [diff] [review]
Patch

Approval Request Comment
[Feature/Bug causing the regression]: macOS 10.14
[User impact if declined]: Modal dialogs (upload, download etc.) become unresponsive after a few seconds of being open and hang the browser.
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: Yes. It has to be verified that modal dialogs continue to be responsive. This can be verified by opening the "file open" dialog from File -> Open File... and traversing folder structures for several minutes. We also need to make sure that the crash originally fixed in bug 678607 does not reappear on all currently supported versions of macOS.
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: Minimal
[Why is the change risky/not risky?]: The main risk is that some versions of macOS might run into the crash in bug 678607 again. This risk is minimized by the fact that the fix in bug 678607 was to work around a bug in gcc. We no longer use gcc.
[String changes made/needed]: none


[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: This bug has a very high, negative impact on Firefox users on macOS 10.14 by hanging Firefox in a way that requires killing the process via Activity Monitor or from the Terminal.
User impact if declined: see above
Fix Landed on Version: 64
Risk to taking this patch (and alternatives if risky): see above
String or UUID changes made by this patch: see above

Comment 73

[ovidiu boca[:Ovidiu]]

Hi Stephen,

I tested the initial issue reported in this bug, the hang, with the latest Nightly build 64.0a1(2018-09-30) on iMac and MacBook with Mac OS X 10.14 and I can confirm the fix, I'm not able to reproduce the issue any more.
I will verify this on beta and release after the uplift.

About the second issue, the one from bug 678607: I tested this with MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports) 2,3 GHz Intel Core i5, 8Gb memory and Intel Iris Plus Graphics 640  1536MB with 10.14 and 10.13 with the latest Nightly build 64.0a1(2018-09-30) and I can't reproduce the issue. 
Stephen, please let me know if I need to investigate this issue any further.

Comment 74

[Pascal Chevrel:pascalc]

Comment on attachment 9013125 [details] [diff] [review]
Patch

Uplift accepted for 63 beta 11, thanks.

Comment 75

[Julien Cristau [:jcristau]]

Comment on attachment 9013125 [details] [diff] [review]
Patch

approved for 62.0.3 and 60.2.2esr

Comment 76

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-release/rev/d7a52857cd86

Comment 77

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr60/rev/d100ed05cbe4

(In reply to Markus Stange [:mstange] from comment #52)
> It would probably be worth going through the entire widget/cocoa code and
> auditing all of these types of workarounds.

AFAIK, this is twice we've been burned like this during the 10.14 cycle. Completely agree that we need to audit our code for other workarounds that might be lurking to burn us down the road.

Comment 78

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/releases/mozilla-beta/rev/3fa0c4d514c9

Comment 79

[Stephen A Pohl [:spohl]]

(In reply to ovidiu boca[:Ovidiu] from comment #73)
> About the second issue, the one from bug 678607: I tested this with MacBook
> Pro (13-inch, 2017, Two Thunderbolt 3 ports) 2,3 GHz Intel Core i5, 8Gb
> memory and Intel Iris Plus Graphics 640  1536MB with 10.14 and 10.13 with
> the latest Nightly build 64.0a1(2018-09-30) and I can't reproduce the issue. 
> Stephen, please let me know if I need to investigate this issue any further.

Since we're going to release this in the next dot release I would feel more comfortable if we tested it on all supported versions of macOS. Unless this would require an excessive amount of effort, I think we should go ahead and test this on 10.9 and above.

Comment 81

[Sveon]

I'm using the latest Nightly and I still have issues with file open/save dialogs, but as I pointed out before, my issues occur with any browser on macOS Mojave.

Let's say I want to attach a file in Gmail. The dialog opens. I select something and then the browser freezes (spinning beachball) for about 10 seconds. Then it recovers and I can continue what I'm doing.

Today I started Nightly from the Terminal and I got these messages:

These appear after opening the file dialog:

2018-10-02 13:23:17.340 plugin-container[23120:6042317] _CFURLCopyResourcePropertyValuesAndFlags failed because it was passed an URL which has no scheme
2018-10-02 13:23:17.341 plugin-container[23120:6042317] _CFURLCopyResourcePropertyValuesAndFlags failed because it was passed an URL which has no scheme
2018-10-02 13:23:17.354 plugin-container[23120:6042317] _CFURLCopyResourcePropertyValuesAndFlags failed because it was passed an URL which has no scheme
2018-10-02 13:23:17.355 plugin-container[23120:6042317] _CFURLCopyResourcePropertyValuesAndFlags failed because it was passed an URL which has no scheme
objc[23119]: Class FIFinderSyncExtensionHost is implemented in both /System/Library/PrivateFrameworks/FinderKit.framework/Versions/A/FinderKit (0x7fff8a9501d0) and /System/Library/PrivateFrameworks/FileProvider.framework/OverrideBundles/FinderSyncCollaborationFileProviderOverride.bundle/Contents/MacOS/FinderSyncCollaborationFileProviderOverride (0x18571ddc8). One of the two will be used. Which one is undefined.

This appears once the freezing stops:

[Parent 23119, Gecko_IOThread] WARNING: pipe error: Broken pipe: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 729

Hope this helps!

Comment 82

[Stephen A Pohl [:spohl]]

(In reply to Sveon from comment #81)
> I'm using the latest Nightly and I still have issues with file open/save
> dialogs, but as I pointed out before, my issues occur with any browser on
> macOS Mojave.

Hi Sveon, this does not seem like the same issue as the one that has been fixed in this bug and since it affects more products than just Firefox, you are most likely encountering an Apple bug. It would be good to file this bug with Apple: https://developer.apple.com/bug-reporting/

Comment 85

[ovidiu boca[:Ovidiu]]

We tested the issue from description and also the issue from bug 678607 on MacBook using the following OSes: Mac OS X 10.14, Mac OS X 10.13, Mac OS X 10.12, Mac OS X 10.11 with Nightly 64.0a1(2018-10-01), Firefox Beta 63.0b11, Firefox release candidate 62.0.3 and Firefox ESR candidate 60.2.2(build2). We can confirm that this issue is fixed and we can confirm that the issue from bug 678607 is not reproducible.  

Note: About the 10.9 and 10.10 Mac OS, we are trying to install them on some old machines and I will update this bug when I have some results.

Comment 91

[Marcia Knous [:marcia]]

(In reply to Markus Stange [:mstange] from comment #52)
> Comment on attachment 9013125 [details] [diff] [review]
> Patch
> 
> Good find. And also rather unfortunate that it ended up being our fault
> after all :(
> It would probably be worth going through the entire widget/cocoa code and
> auditing all of these types of workarounds.

Markus: This was a good thought - should we file a spinoff bug for the code audit?

Comment 92

[Markus Stange [:mstange]]

Stephen filed bug 1503982 about this.