Double click to minimize to dock does not work when drawInTitlebar is enabled for a window

RESOLVED FIXED in mozilla24

Status

()

Core
Widget: Cocoa
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: fiveNinePlusR, Assigned: jsbruner)

Tracking

({regression})

Trunk
mozilla24
x86
Mac OS X
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 9 obsolete attachments)

4.45 KB, patch
smichaud
: review+
Details | Diff | Splinter Review
3.55 KB, patch
mstange
: review+
Details | Diff | Splinter Review
2.62 KB, patch
jsbruner
: review+
Details | Diff | Splinter Review
(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:21.0) Gecko/20130320 Firefox/21.0
Build ID: 20130320042012

Steps to reproduce:

Double click on the title bar in OS X 10.7.5. 


Actual results:

Nothing


Expected results:

when the appropriate system setting is checked (in System Preferences | General | Double-click a window's title bar to minimize) the window should minimize to the dock.
Also true in OSX 10.8.2 with Nightly.  With Firefox 19.0.2, double clicking the title bar works as it should and minimizes the app into the dock. So the regression window must be between Firefox 19 and 22. 

Not sure if this is a Core issue or not.
Status: UNCONFIRMED → NEW
Component: Untriaged → General
Ever confirmed: true
Keywords: regressionwindow-wanted
This was working up to the 2013-03-20 Nightly build. I haven't narrowed it further.
(Reporter)

Comment 3

5 years ago
This has been broken on my Aurora builds for a weeks now. Are those not the nightly builds?
Hi mapish - Nightly is every night, and Aurora is released every 6 weeks. Here's the link for the nightly builds: http://nightly.mozilla.org/   

This explains the release dates: https://wiki.mozilla.org/Releases
(Reporter)

Comment 5

5 years ago
I see. Thanks for the clarification... I was confused by the fact that Aurora downloads new updates every night so I thought it was on the daily build level. What are they updating every night?
Component: General → Event Handling
Product: Firefox → Core

Comment 6

5 years ago
Actually, Aurora builds, as well as Nightly builds are built every day. They are both "nightly" with the main difference that what is usually called Nightly, is built from mozilla-central (currently Firefox 22), and Aurora is built from mozilla-aurora (currently Firefox 21).

What happens every 6 weeks is the merge: trunk becomes Nightly, what was Nightly becomes Aurora, what was Aurora moves to Beta, and the version that was in beta gets released.

For more details, go to http://mozilla.github.com/process-releases/draft/development_specifics/
(In reply to mapish from comment #5)

Not able to reproduce it on Nightly and Aurora (2013-03-20) and on FF 20b6 on Mac OS 10.7.5:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:20.0) Gecko/20100101 Firefox/20.0(20130320062118)
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:21.0) Gecko/20130320 Firefox/21.0(20130320042012)
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:22.0) Gecko/20130320 Firefox/22.0(20130320031103)

Using system setting from Comment 0, Firefox works as expected. 

Mapish are you sure you are not in Full Screen mode? Because if you are, it is expected FF to not minimize, as long as the other apple applications don't. (See Safari)

In addition please let us know if you can still reproduce this issue on latest builds:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/

And yes, Aurora is built daily as Ioana said in Comment 6.
Flags: needinfo?(mapish)
(Reporter)

Comment 8

5 years ago
so I downloaded the latest nightly and found out that the issue is still there. On a hunch I tried disabling a few things starting with adblock. The problem was not with adblock as I suspected but with an appearance. The disabling of the grey and black theme from MaDonna resolved this issue. It seems that enabling any of my installed themes will interfere with the minimize to dock feature so it's not just one problem theme.

Does this require a new bug because of the new information or is this one sufficient?
Flags: needinfo?(mapish)
(Reporter)

Comment 9

5 years ago
In addition to my last comment I would like to make an observation that enabling the default theme seems to make the browser interact much more quickly. I am on a fairly fast computer and it caused a noticeable increase in speed. This might be worth a new bug report?

Updated

5 years ago
Component: Event Handling → Extension Compatibility
Product: Core → Firefox

Updated

5 years ago
Summary: Double click to minimize to dock does not work. → Double click to minimize to dock does not work when any theme is applied

Comment 10

5 years ago
mapish, there are two cases here for both your issues. You need to find out where they fit, before moving forward:

Case 1: the issue reproduces on all Firefox versions when themes are applied, which means this is an issue with the themes. 
-> Results: This bug will be set as invalid since this is not a Firefox issue. You should contact the themes developers (for the themes of interest to you), and let them know about this issue, so they can fix it.

Case 2: the issue only reproduces on some Firefox versions (usually the last x ones), which means this is a Firefox issue.
-> Results: after a regression window is found, someone can start working on fixing this bug.

If the issue in comment 9 fits in the 2nd case, please file a new bug for it.
I'd done following investigations:

Minimizing to docs works as expected on FF 20RC (with no theme or with any theme enabled). On latest nightly (2013-03-29) it doesn't minimize using any theme from: https://addons.mozilla.org/en-us/firefox/themes/ , but it does with no theme enabled.

So this looks to be Ioana's Case 1 from Comment 10. Based on my investigations done, this is an issue with the themes not with Firefox.

Regression Range:

Last good nightly: 2013-02-06
First bad nightly: 2013-02-07

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bc108d2ce8d1&tochange=04e13fc9dbff

Since this is not a Firefox issue -> Resolved Invalid.

Investigations done on MacOS 10.7.5
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID

Comment 12

5 years ago
MarioMi, since there is a last good build on which this issue didn't reproduce, it means the bug is with Firefox, no the themes.
Status: RESOLVED → REOPENED
Keywords: regressionwindow-wanted → regression
Resolution: INVALID → ---

Updated

5 years ago
Status: REOPENED → NEW
I am 99% sure this is caused by bug 647216.

Updated

5 years ago
Component: Extension Compatibility → Widget: Cocoa
Product: Firefox → Core
> I am 99% sure this is caused by bug 647216.

I've confirmed this.

I tested with the "Summer Explosion" theme on OS X 10.8.3.

It's a pain to test for this bug on MountainLion.  AppleMiniaturizeOnDoubleClick is off by default (as it is on Lion).  But unlike on Lion, there doesn't appear to be any way to change this setting in any of the System pref panels.

Instead you've got to do the following at a Terminal prompt:

defaults write .GlobalPreferences AppleMiniaturizeOnDoubleClick '1'
Blocks: 647216
I am on OSX 10.8.3, and can change that setting in the system preferences, in the Dock panel, Double-click a window's title bar to minimize.
> in the Dock panel, Double-click a window's title bar to minimize

Yes, I see it now too.  I guess I didn't look hard enough.

Don't know why Apple moved the setting, though.  I think it makes a lot better sense in the General panel.
(Reporter)

Comment 17

5 years ago
Is there a reason that this bug hasn't reopened the bug it blocks?

Comment 18

5 years ago
Same issue happens when you are in private mode, double clicking the title bar does not minimize the window. Same issue? Assuming that the private mode window is themed.
Version: 21 Branch → Trunk

Updated

5 years ago
Duplicate of this bug: 870341
The current problem here is that our "custom" titlebar that we draw when drawInTitlebar is enabled, does not respond to the correct mouse events here.

We have a few choices here:

A. Use native code and set up a mouse event responder so we can track double clicks on the titlebar, and then call performMiniaturize when necessary. (Probably the hardest route, but the most reliable)

B. Add a click listener and use some logic on the titlebar vbox. In addition, we would need to add a pref that we can change depending on the System Preferences toggle for accomplishing double-click to minimize. (This is potentially the ideal route.)

I personally suggest route B, it is probably the easiest, we can already access the pref by doing something like:

NSString *const MDAppleMiniaturizeOnDoubleClickKey = @"AppleMiniaturizeOnDoubleClick";
NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];
[userDefaults addSuiteNamed:NSGlobalDomain];
bool willMinimizeOnDoubleClick = [[userDefaults objectForKey:MDAppleMiniaturizeOnDoubleClickKey] boolValue];

Then just set the pref accordingly. The hard(er) part will be detecting a change in this preference *while* the app is running.
I'll go ahead and work on this...
Assignee: nobody → josiah
Summary: Double click to minimize to dock does not work when any theme is applied → Double click to minimize to dock does not work when drawInTitlebar is enabled for a window
Created attachment 752527 [details] [diff] [review]
Patch V1

Alright. So this patch fixes all known problems. Themes now function properly, along with private windows, and any other windows that use drawInTitlebar.

I'm going to throw this up in try to run the tests, but in the meantime I am asking Stephen for some feedback on the Cocoa parts.

Stephen: I decided to go the route of adding an observer on [NSDistributedNotificationCenter defaultCenter] checking for the "AppleNoRedisplayAppearancePreferenceChanged" change. This change only happens on certain System Preference toggle actions, which is much better than checking every user default change.

After I receive this call, I just use the code I showed above to verify that preference directly.

The potential issue here is that AppleNoRedisplayAppearancePreferenceChanged is an undocumented notification, but I believe it should be quite stable. Because the notification is not restricted to only the "minimize windows by double clicking on the title bar" checkbox, the chances of Apple breaking this call seems unlikely, especially in this use case. Even Webcore uses it (See: http://opensource.apple.com/source/WebCore/WebCore-528.14/platform/mac/ScrollbarThemeMac.mm)

But I could be overlooking something quite serious, so I would like your opinion on this.
Attachment #752527 - Flags: feedback?(smichaud)
Status: NEW → ASSIGNED
Comment on attachment 752527 [details] [diff] [review]
Patch V1

This looks promising.  But I want to do some testing (and digging around in Apple's docs and "strings" output) before I say OK.

Since I'm at a "work week", that may take a day or two.
Comment on attachment 752527 [details] [diff] [review]
Patch V1

I still haven't had a chance to test this, but I've dug a bit into AppKit code back to SnowLeopard.  From what I've seen the Cocoa widgets part of your patch should work fine.  You should probably get someone else to look at the XUL part, though.

It's not just WebKit.  The AppKit framework also uses the approach you chose.  It registers with the NSDistributedNotificationCenter to receive "AppleNoRedisplayAppearancePreferenceChanged" notifications.  On Lion and up these get sent to the (undocumented) -[NSApplication _behaviorOnDoubleClickChanged] method.  On SnowLeopard and below they get sent to the -[NSApplication _setMinimizeOnDoubleClick] method.  Both of these methods check the value of "AppleMiniaturizeOnDoubleClick".  So your patch should be quite safe.

Still, though, you should do your own testing on all our supported OS X platforms -- MountainLion, Lion and SnowLeopard.

I do have a question and a comment:

+  [userDefaults addSuiteNamed:NSGlobalDomain];

Why do you make this call?

+- (void)gotIt:(NSNotification*)notification {

You should change the name from "gotIt" to something more specific -- something like "checkMinimizeOnDoubleClickSetting".
Attachment #752527 - Flags: feedback?(smichaud) → feedback+
Cool.

(In reply to Steven Michaud from comment #24)
> I do have a question and a comment:
> 
> +  [userDefaults addSuiteNamed:NSGlobalDomain];
> 
> Why do you make this call?

:) Just now realized that userDefaults includes NSGlobalDomain by default, so this is indeed redundant.

> 
> +- (void)gotIt:(NSNotification*)notification {
> 
> You should change the name from "gotIt" to something more specific --
> something like "checkMinimizeOnDoubleClickSetting".

Whoops. Yeah, I'll do that, I only used gotIt: for testing purposes, forgot to change the name.
Created attachment 752855 [details] [diff] [review]
Patch V1.1

Updated patch addresses Stephen's comments and adds a comment in the code about the undocumented call.

Since Stephen basically already reviewed parts of the Cocoa code, he may as well do the rest. :)

Flagging Dao for review on the xul/js parts. (Dao, if you are not the right person for this, feel free to pass on the flag)
Attachment #752527 - Attachment is obsolete: true
Attachment #752855 - Flags: review?(smichaud)
Attachment #752855 - Flags: review?(dao)
Comment on attachment 752855 [details] [diff] [review]
Patch V1.1

This looks fine to me.

A couple of style nits, though:

+  [[NSDistributedNotificationCenter defaultCenter] ...

This and the comment above it should be reflowed so that no line (aside from the one containing the URL) is longer than about 80 characters.

+  if (shouldMinimize)
+    Preferences::SetBool("browser.minimizeOnTitlebarDoubleClick", true);
+  else
+    Preferences::SetBool("browser.minimizeOnTitlebarDoubleClick", false);

The if and else blocks should both have curly braces ({}) around them.  Like so:

+  if (shouldMinimize) {
+    Preferences::SetBool("browser.minimizeOnTitlebarDoubleClick", true);
+  } else {
+    Preferences::SetBool("browser.minimizeOnTitlebarDoubleClick", false);
+  }
Attachment #752855 - Flags: review?(smichaud) → review+
Comment on attachment 752855 [details] [diff] [review]
Patch V1.1

The browser.minimizeOnTitlebarDoubleClick pref set by widget code is rather confusing, as setting it manually won't have an effect -- nor should it, because we don't /want/ a pref for this behavior; we just want to follow the system settings. Can't we have an API exposing the system setting?
Instead of propagating the system pref settings to JS, maybe we should handle this completely in widget land. What I'm thinking of:
In -[ChildView mouseUp]:
if ([theEvent clickCount] == 2 &&
    [self shouldMinimizeOnTitlebarDoubleClick] &&
    [theEvent locationInWindow].y < titlebarHeight &&
    [[self window] isMovableByWindowBackground]) {
  [[self window] miniaturize];
}
-[ChildView shouldMinimizeOnTitlebarDoubleClick] would need to be written.
isMovableByWindowBackground is only true if the mouse is currently over a part in the titlebar where dragging would move the window.
Note that, like the JS approach, but unlike the native behavior, this wouldn't work while a sheet is open on this window.
There might be a problem with this approach. Let's say titlebarHeight is 22 - that would restore the old behavior. But then the strip that minimizes the window overlaps with the Australis tabbar, and in the overlapping part a double click will both open a new tab and minimize the window.
So we shouldn't minimize for double clicks which are handled by JS. Luckily, the code that opens a new tab on double click (the dblclick handler in tabbrowser.xml) calls event.preventDefault(). This is reflected back into nsChildView as the return code of DispatchWindowEvent, which is called in mouseUp, where the new code would be added. So the "if" condition from comment 29 would need to be extended by a "DispatchWindowEvent returned true/false" condition. (I'm not sure whether true or false means "preventDefault was called", you'd need to test that.)
Woke up today with a bad cold, so I'll try to have a new patch up in the next two days.
Created attachment 754288 [details] [diff] [review]
Patch V 2.0

Updated patch that avoids using javascript/DOM. For now I am keeping the double-click will open a new tab/minimize by stopping mouseUp: events entirely on double-click. Which I would assume is not what we want in the end.

Markus, I was could not figure out how to use this "DispatchWindowEvent" you mentioned. I searched around and could not find any code that was similar to what we wanted. Could you explain a little more on how to use this?

Either way, I guess this brings up a separate issue. Which do we value more, double-clicking to add a tab, or double-clicking to minimize. In this patch I reduce the titlebar hit zone to 18px, thereby allowing tabs to be added without disruption, while keeping the ability to minimize via this 18px range. We could:

A. Keep it pretty much how it is in this patch (Use a smaller titlebar and keep a hit area for both items)

B. Detect if we are in the tab zone like Markus suggested, and *only* add a tab, ignore minimizing.

C. Keep a 22px hit area for the titlebar, and if the user clicks on an overlapping section, do the minimize instead of adding a tab.

D. Remove adding tabs via double-click entirely, which seems like a bad idea.

ui-feedback?
Attachment #752855 - Attachment is obsolete: true
Attachment #752855 - Flags: review?(dao)
Ccing Jennifer and Alex to see if they have any input on the above issue. ^
(In reply to Josiah Bruner [:JosiahOne] from comment #33)
> Markus, I was could not figure out how to use this "DispatchWindowEvent" you
> mentioned. I searched around and could not find any code that was similar to
> what we wanted. Could you explain a little more on how to use this?

Sure.
You'll need to add your code to nsChildView.mm, not nsCocoaWindow.mm. (The code you're adding your stuff to in this patch has already been removed in bug 676241.) Two other places in nsChildView.mm where the result of DispatchWindowEvent is used are -[ChildView updateWindowDraggableStateOnMouseMove:], -[ChildView inactiveWindowAcceptsMouseEvent:].
> D. Remove adding tabs via double-click entirely, which seems like a bad idea.

We did this on Windows.
(In reply to Dão Gottwald [:dao] from comment #36)
> > D. Remove adding tabs via double-click entirely, which seems like a bad idea.
> 
> We did this on Windows.

Yeah, the more I think about this the more I think it might be a good idea.

Adding a needinfo flag for ux-feedback about Comment 33
Flags: needinfo?
Created attachment 756148 [details] [diff] [review]
Patch.

Clearing the ui-needinfo for now. I would rather just land this as-is and we can decide what to do UX-wise later. This adds all functionality discussed.

Flagging Markus for review.
Attachment #754288 - Attachment is obsolete: true
Attachment #756148 - Flags: review?(mstange)
Flags: needinfo?
Comment on attachment 756148 [details] [diff] [review]
Patch.

Review of attachment 756148 [details] [diff] [review]:
-----------------------------------------------------------------

Looks very good apart from the unnecessary hittest event issue.

::: widget/cocoa/nsChildView.mm
@@ +4060,5 @@
>      return;
>  
> +  int hardTitlebarHeight = 22; // For now we must hard code in the height of the titlebar.
> +
> +  nsMouseEvent hitTestEvent(true, NS_MOUSE_MOZHITTEST, mGeckoChild, nsMouseEvent::eReal);

I had something different in mind: Instead of sending an NS_MOUSE_MOZHITTEST event here, just send the NS_MOUSE_BUTTON_UP double click event below (using the existing code) and look at the preventDefault return value of that event.

The NS_MOUSE_MOZHITTEST event shouldn't be necessary because the "is that point of the window draggable" has already happened when the mouse moved there, and the result is reflected in the value of [[self window] isMovableByWindowBackground], so you have that part covered already.

@@ +4070,5 @@
> +      [self shouldMinimizeOnTitlebarDoubleClick] &&
> +      locationInTitlebar < hardTitlebarHeight &&
> +      [[self window] isMovableByWindowBackground]) {
> +    [[self window] miniaturize:self];
> +  } 

whitespace at the end of the line
Created attachment 756241 [details] [diff] [review]
Patch.

Fixed whitespace and switched to NS_MOUSE_BUTTON_UP for the nsMouseEvent.
Attachment #756148 - Attachment is obsolete: true
Attachment #756148 - Flags: review?(mstange)
Attachment #756241 - Flags: review?(mstange)
Comment on attachment 756241 [details] [diff] [review]
Patch.

Almost. But now you're calling DispatchWindowEvent twice - there's an existing call further down. What I meant was that you use the return value of that existing call.
Created attachment 756247 [details] [diff] [review]
Patch.

Made that fix. Not sure if you meant to call DispatchEvent where it was originally, but I moved it up. Hopefully that's okay.
Attachment #756241 - Attachment is obsolete: true
Attachment #756241 - Flags: review?(mstange)
Attachment #756247 - Flags: review?(mstange)
(In reply to Josiah Bruner [:JosiahOne] from comment #42)
> Not sure if you meant to call DispatchEvent where it was
> originally

Yes, that's what I meant, otherwise geckoEvent.button and geckoEvent.pluginEvent won't be set correctly. So just move all the new code down to where the original call to mGeckoChild->DispatchWindowEvent was.
Comment on attachment 756247 [details] [diff] [review]
Patch.

Review of attachment 756247 [details] [diff] [review]:
-----------------------------------------------------------------

::: widget/cocoa/nsChildView.mm
@@ +4695,5 @@
> +- (BOOL)shouldMinimizeOnTitlebarDoubleClick
> +{
> +  NSString *MDAppleMiniaturizeOnDoubleClickKey = @"AppleMiniaturizeOnDoubleClick";
> +  NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];
> +  bool shouldMinimize = [[userDefaults objectForKey:MDAppleMiniaturizeOnDoubleClickKey] boolValue];

80 character limit. :-)
Created attachment 756319 [details] [diff] [review]
Patch.

Alright. Here we are.
Attachment #756247 - Attachment is obsolete: true
Attachment #756247 - Flags: review?(mstange)
Attachment #756319 - Flags: review?(mstange)
Created attachment 756322 [details] [diff] [review]
Patch.

Just to be safe...
Attachment #756319 - Attachment is obsolete: true
Attachment #756319 - Flags: review?(mstange)
Attachment #756322 - Flags: review?(mstange)
Comment on attachment 756322 [details] [diff] [review]
Patch.

Great!

The hardcoded titlebarheight irks me a little, so I'm fixing it before checkin.
Attachment #756322 - Flags: review?(mstange) → review+
Created attachment 757357 [details] [diff] [review]
tweaked patch

This now uses [window titlebarHeight]. I've also tweaked the detection to include the toolbar part of unified toolbars, so that for example in the bookmarks library window you can double click the whole unified toolbar to minimize the window, which matches the native experience.
Attachment #756322 - Attachment is obsolete: true
Attachment #757357 - Flags: review?(smichaud)

Comment 49

5 years ago
I'm using Mac Firefox 21 with Snow Leopard (10.6.8). Double-clicking the title bar minimizes the window normally _only_ if the default FF theme is in effect. Double-clicking the title bar does nothing if _any_ custom theme is in effect (I've tried quite a few). Since this affects all custom themes, I don't think you can argue (as some above seem to) that it's a "themes problem" that's the responsibility of the themes developers. This is clearly a Firefox problem.

BTW, all my other applications minimize normally to the dock when their title bar is double-clicked... including other browsers, MS Word, etc.
Created attachment 757817 [details] [diff] [review]
tweaked patch

there was a typo in the previous patch
Attachment #757357 - Attachment is obsolete: true
Attachment #757357 - Flags: review?(smichaud)
Attachment #757817 - Flags: review?(smichaud)
Comment on attachment 757817 [details] [diff] [review]
tweaked patch

Looks fine to me.

I tested it on OS X 10.8.3, 10.7.5 and 10.6.8, with and without a lightweight theme.  I didn't see any problems.

I also tested with the AppleMiniaturizeOnDoubleClick setting off (the default on all three platforms).  Things worked as expected -- double-clicking in the titlebar no longer had any effect.
Attachment #757817 - Flags: review?(smichaud) → review+
Requesting checkin.
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/2464333908a7
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24

Updated

5 years ago
Duplicate of this bug: 873135
Created attachment 761758 [details] [diff] [review]
Fix for Aurora.

Patch for the Aurora branch. Had to tweak it slightly. Markus, does the changed title bar detection code look fine?
Attachment #761758 - Flags: review?(mstange)
Comment on attachment 761758 [details] [diff] [review]
Fix for Aurora.

Actually, you can leave out the nsCocoaWindow.mm changes completely. The problem that the comment mentions didn't occur before bug 676241 part 4.
r=me with that removed
Attachment #761758 - Flags: review?(mstange) → review+
Created attachment 761771 [details] [diff] [review]
Fix for Aurora.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Draw in title bar.
User impact if declined: Users won't be able to double-click to minimize on any windows that use draw in titlebar. E.G. Personas and the private browsing mode.
Testing completed (on m-c, etc.): Been on m-c for awhile now.
Risk to taking this patch (and alternatives if risky): Very little risk.
String or IDL/UUID changes made by this patch: N/A
Attachment #761771 - Flags: review+
Attachment #761771 - Flags: approval-mozilla-aurora?
Comment on attachment 761771 [details] [diff] [review]
Fix for Aurora.

We're close to the beta merge - let's just ride the trains.
Attachment #761771 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora-

Comment 61

5 years ago
It's very discouraging to see "Resolved/Fixed" stamped on this page. Here it is almost three months later (September 2013), and I've just upgraded from MacFF 22 to MacFF 23, and the problem is still NOT fixed. Enabling any third-party theme prevents double-clicking the FF title bar from doing anything at all. The window will only minimize if the default theme is in effect. I'm used to Mac Firefox having numerous small problems that the Windows version doesn't have, but after months of this, and seeing "resolved/fixed/fixed" on multiple pages around here, this is really upsetting.

As I said before, it's unreasonable to claim that "the problem is with the themes, not with Firefox." That's tantamount to saying that ALL the themes developers have been making the same coding error. Please.
(In reply to Jonas Smithson from comment #61)
> It's very discouraging to see "Resolved/Fixed" stamped on this page. Here it
> is almost three months later (September 2013), and I've just upgraded from
> MacFF 22 to MacFF 23, and the problem is still NOT fixed.

This bug is fixed as of Firefox 24 (see the "Target Milestone" field), which is going to be released in the near future.
You need to log in before you can comment on or make changes to this bug.