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

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

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.

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

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

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!

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.

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?

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.

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.

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?

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.

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

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

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

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.

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.

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.

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

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

Added to 62 relnotes as a known issue.

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

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

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

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.

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?

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

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

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

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.

Able to reproduce. Looking into it.

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.

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

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.

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.

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.

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.

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.

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

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

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

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

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

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

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?

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

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

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!

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!

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?

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

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

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

Thanks.

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

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

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

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

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

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

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 on attachment 9013125 [details] [diff] [review] Patch Uplift accepted for 63 beta 11, thanks.

Comment on attachment 9013125 [details] [diff] [review] Patch approved for 62.0.3 and 60.2.2esr

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.

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

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!

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

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.

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

Stephen filed bug 1503982 about this.