Closed Bug 1199547 Opened 5 years ago Closed 5 years ago

Cannot click "Print" or "Save Page As" in "File" after closing the "Print" dialog


(Core :: Widget: Cocoa, defect)

Not set



Tracking Status
firefox41 --- affected
firefox42 --- affected
firefox43 --- affected
firefox44 --- affected
firefox48 --- fixed


(Reporter: TYLin, Assigned: spohl)



(Keywords: regression)


(2 files)

I can reproduce this issue on master and Firefox 40 on Mac OS 10.10.5

Step to reproduce:
1. Open arbitrary web page.
2. Press either "Command + P" or "Command + S" to bring up the dialog to print or save the page.
3. Press "esc" to close the dialog.
4. Click on "File" to open the menu on the toolbar.

Actual results:
Action items related to the page such as "Close", "Save Page As", "Print" are disabled. See the screenshot attached.

Expected results:
The action items should not be disabled.

If you repeat step 2, 3, 4 over and over, the actual and expected results will appear interchangeably. And I always get the expected results if I use mouse to open "Print" from the "File" menu in step 2.
I don't remember the menu was broken in this way. Might be a regression.
Keywords: qawanted
Ting, can you use the mozregression tool to try to narrow this down further? I don't have access to a Mac and this doesn't reproduce on Windows.

Flags: needinfo?(tlin)
I got this regression range by mozregression.

110:37.46 LOG: MainThread Bisector INFO Narrowed nightly regression window from [2014-01-12, 2014-01-14] (2 days) to [2014-01-13, 2014-01-14] (1 days) (~0 steps left)
110:37.46 LOG: MainThread main INFO Got as far as we can go bisecting nightlies...
110:37.46 LOG: MainThread Bisector INFO Last good revision: 12d3ba62a599
110:37.46 LOG: MainThread Bisector INFO First bad revision: 34dddf6f7ec1
110:37.46 LOG: MainThread Bisector INFO Pushlog:

If this can only reproducable on Mac, it guess this might be a regression by bug 722676.
Component: General → Widget: Cocoa
Flags: needinfo?(tlin)
Product: Firefox → Core
This still reproduces on current beta. Markus, who could prioritize this appropriately now that smichaud is retired?
Blocks: 722676
Flags: needinfo?(mstange)
I wish I knew. spohl or myself, probably.

Stephen, do you have time to look into this? If not, I guess I'll do it once I've fixed my current list of recent regressions.
Flags: needinfo?(mstange) → needinfo?(spohl.mozilla.bugs)
I'll try to make some time for this. Leaving n-i for myself until I've done so.
I've been unable to properly "fix" the workaround that was implemented in bug 722676 to work on OSX 10.10 and above. However, I'm suggesting that we back out the workaround from bug 722676 for the following reasons:
1. The original issue (bug 722676) didn't affect OSX 10.9 and above.
2. The original issue (bug 722676) simply left a menu item highlighted on OSX 10.5 and 10.7, while the workaround implemented there causes broken functionality on at least 10.10 and above (this bug).
3. According to bug 722676 comment 15, the patch was working around a native OSX bug that appears to be fixed in later versions of OSX (10.9+).

Markus, does this seem reasonable to you? Or should we invest more time trying to get the original workaround to work on OSX 10.9 and above without causing this bug?
Assignee: nobody → spohl.mozilla.bugs
Flags: needinfo?(spohl.mozilla.bugs)
Attachment #8738207 - Flags: review?(mstange)
For what it's worth, backing out bug 722676 sounds reasonable to me :-)
Comment on attachment 8738207 [details] [diff] [review]
Backout workaround from bug 722676

Review of attachment 8738207 [details] [diff] [review]:

Seems reasonable.
Attachment #8738207 - Flags: review?(mstange) → review+
Keywords: checkin-needed
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
You need to log in before you can comment on or make changes to this bug.