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

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[fiveNinePlusR]

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.

Comment 1

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 2

[Liz Henry (:lizzard) (relman/hg->git project)]

This was working up to the 2013-03-20 Nightly build. I haven't narrowed it further.

Comment 3

[fiveNinePlusR]

This has been broken on my Aurora builds for a weeks now. Are those not the nightly builds?

Comment 4

[Liz Henry (:lizzard) (relman/hg->git project)]

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

Comment 5

[fiveNinePlusR]

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?

Comment 6

[Ioana (away)]

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/

Comment 7

[Mihai Morar, (:MihaiMorar)]

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

Comment 8

[fiveNinePlusR]

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?

Comment 9

[fiveNinePlusR]

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?

Comment 10

[Ioana (away)]

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.

Comment 11

[Mihai Morar, (:MihaiMorar)]

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

Comment 12

[Ioana (away)]

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.

Comment 13

[Josh Matthews [:jdm]]

I am 99% sure this is caused by bug 647216.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

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

Comment 15

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 16

[Steven Michaud [:smichaud] (Retired)]

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

Comment 17

[fiveNinePlusR]

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

Comment 18

[José Jeria]

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.

Comment 20

[Josiah Bruner [:jsbruner]]

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.

Comment 21

[Josiah Bruner [:jsbruner]]

I'll go ahead and work on this...

Comment 22

[Josiah Bruner [:jsbruner]]

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

Comment 23

[Steven Michaud [:smichaud] (Retired)]

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 24

[Steven Michaud [:smichaud] (Retired)]

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

Comment 25

[Josiah Bruner [:jsbruner]]

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.

Comment 26

[Josiah Bruner [:jsbruner]]

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

Comment 27

[Steven Michaud [:smichaud] (Retired)]

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);
+  }

Comment 28

[Dão Gottwald [:dao]]

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?

Comment 29

[Markus Stange [:mstange]]

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.

Comment 30

[Markus Stange [:mstange]]

Note that, like the JS approach, but unlike the native behavior, this wouldn't work while a sheet is open on this window.

Comment 31

[Markus Stange [:mstange]]

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

Comment 32

[Josiah Bruner [:jsbruner]]

Woke up today with a bad cold, so I'll try to have a new patch up in the next two days.

Comment 33

[Josiah Bruner [:jsbruner]]

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

Comment 34

[Josiah Bruner [:jsbruner]]

Ccing Jennifer and Alex to see if they have any input on the above issue. ^

Comment 35

[Markus Stange [:mstange]]

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

Comment 36

[Dão Gottwald [:dao]]

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

We did this on Windows.

Comment 37

[Josiah Bruner [:jsbruner]]

(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

Comment 38

[Josiah Bruner [:jsbruner]]

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

Comment 39

[Markus Stange [:mstange]]

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

Comment 40

[Josiah Bruner [:jsbruner]]

Attachment: Patch.

Fixed whitespace and switched to NS_MOUSE_BUTTON_UP for the nsMouseEvent.

Comment 41

[Markus Stange [: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.

Comment 42

[Josiah Bruner [:jsbruner]]

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

Comment 43

[Markus Stange [: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 44

[Stephen A Pohl [:spohl]]

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

Comment 45

[Josiah Bruner [:jsbruner]]

Attachment: Patch.

Alright. Here we are.

Comment 46

[Josiah Bruner [:jsbruner]]

Attachment: Patch.

Just to be safe...

Comment 47

[Markus Stange [:mstange]]

Comment on attachment 756322 [details] [diff] [review]
Patch.

Great!

The hardcoded titlebarheight irks me a little, so I'm fixing it before checkin.

Comment 48

[Markus Stange [:mstange]]

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

Comment 49

[Jonas Smithson]

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.

Comment 50

[Markus Stange [:mstange]]

Attachment: tweaked patch

there was a typo in the previous patch

Comment 51

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 52

[Josiah Bruner [:jsbruner]]

Requesting checkin.

Comment 53

[Markus Stange [:mstange]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2464333908a7

Comment 54

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/2464333908a7

Comment 56

[Josiah Bruner [:jsbruner]]

Attachment: Fix for Aurora.

Patch for the Aurora branch. Had to tweak it slightly. Markus, does the changed title bar detection code look fine?

Comment 57

[Markus Stange [: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

Comment 58

[Josiah Bruner [:jsbruner]]

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

Comment 59

[Josiah Bruner [:jsbruner]]

Try run with this patch on Aurora.

https://tbpl.mozilla.org/?tree=Try&rev=0b3f817c0f97

Comment 60

[Alex Keybl [:akeybl]]

Comment on attachment 761771 [details] [diff] [review]
Fix for Aurora.

We're close to the beta merge - let's just ride the trains.

Comment 61

[Jonas Smithson]

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.

Comment 62

[Dão Gottwald [:dao]]

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