1070038 - [10.10] Entire Firefox Window Draggable

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect)

Description

[d.a.]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20140919030202

Steps to reproduce:

It's now possible to move the firefox window by dragging it no matter where you click, even within the content part of the window. It makes selecting text on a website impossible. This looks to be fallout from bug 944836.

Applying the following css rule to the chrome disables dragging entirely:

* {
    -moz-window-dragging: no-drag;
}

But setting it on specific parts of the window (such as #main-window, #browser etc) doesn't disable dragging.

Comment 1

[Markus Stange [:mstange]]

Uhhh that's bad. Are you using any kind of non-default theme?

Comment 2

[d.a.]

(In reply to Markus Stange [:mstange] from comment #1)
> Uhhh that's bad. Are you using any kind of non-default theme?

Tried it with a new profile and it did the same thing.

Comment 3

[Markus Stange [:mstange]]

OK, I see this on 10.10.

Comment 4

[Markus Stange [:mstange]]

Attachment: patch

And this is how we experience first-hand what we're getting ourselves into by using private APIs. :-)

Comment 7

[Devon Hubbard]

regression note:
To confirm the original reported OS vers; this is only reproducible on Yosemite (OS X 10.10).  I can confirm that FirefoxNightly (2014-09-19 and today's 2014-09-21) do not experience this drag window problem when running on Mavericks.

The problem on Yosemite is easily reproducible on many sites Google, Amazon, etc.

Comment 9

[Markus Stange [:mstange]]

I filed bug 1070710 with a window dragging implementation that does not rely on private APIs.

Comment 10

[Dirkjan Ochtman (:djc)]

FYI, http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-09-18-03-02-02-mozilla-central/firefox-35.0a1.en-US.mac.dmg still works. I've downgraded for the moment, since this bug makes the browser really unusable for me.

Comment 12

[Maxime Thirouin]

Where can we enter the workaround css thing put in the first comment ?
I've tried a style using Stylish extension (https://addons.mozilla.org/en-US/firefox/addon/stylish/) with a new rules that can affect everything (I've double check with a stupid background: red !important to be sure) but the -moz-thing doesn't work for me.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 8492599 [details] [diff] [review]
patch

This looks basically OK to me.  So, since it's urgent, I'll r+ it now.  But I want to look further into it, and maybe revise your patch later.

 - (CGSRegionObj)_regionForOpaqueDescendants:(NSRect)aRect forMove:(BOOL)aForMove;
 - (CGSRegionObj)_regionForOpaqueDescendants:(NSRect)aRect forMove:(BOOL)aForMove forUnderTitlebar:(BOOL)aForUnderTitlebar;

The NSView class has *both* of these methods on Yosemite (as you can tell by looking at the output of class-dump on the AppKit framework).  I want to dig further into why the one with aForUnderTitlebar is sometimes used, and sometimes not.

As for using undocumented APIs, we often have no choice.  Though when you do use them, you want to be as safe as possible.  For example, you only want to use (or hook) an API that's widely used by the OS and/or other Apple apps, and that has been around in the same form for a long time.  -[NSView _regionForOpaqueDescendants:forMove:] actually meets both these criteria.  But sometimes (and very rarely) all the care you take isn't enough.

This is one of those cases.  Though -[NSView _regionForOpaqueDescendants:forMove:] still exists, there are now (in Yosemite) some cases where -[NSView _regionForOpaqueDescendants:forMove:forUnderTitlebar:] is used instead of it.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 8492599 [details] [diff] [review]
patch

+// Starting with 10.10, _regionForOpaqueDescendants has a different form, with
+// an additional forUnderTitlebar argument.

Forgot to mention that you should change this comment.

Comment 15

[Markus Stange [:mstange]]

(In reply to Steven Michaud from comment #13)
> Comment on attachment 8492599 [details] [diff] [review]
> patch
> 
> This looks basically OK to me.  So, since it's urgent, I'll r+ it now.  But
> I want to look further into it, and maybe revise your patch later.
> 
>  - (CGSRegionObj)_regionForOpaqueDescendants:(NSRect)aRect
> forMove:(BOOL)aForMove;
>  - (CGSRegionObj)_regionForOpaqueDescendants:(NSRect)aRect
> forMove:(BOOL)aForMove forUnderTitlebar:(BOOL)aForUnderTitlebar;
> 
> The NSView class has *both* of these methods on Yosemite (as you can tell by
> looking at the output of class-dump on the AppKit framework).  I want to dig
> further into why the one with aForUnderTitlebar is sometimes used, and
> sometimes not.

You're right, I didn't notice this.

> As for using undocumented APIs, we often have no choice.

I agree with you, but in this case we actually do have a choice. If you could evaluate the approach in bug 1070710 before spending more time on this one, I think that would be a good idea.

Comment 17

[Markus Stange [:mstange]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8f7dcbde58db

Comment 18

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/8f7dcbde58db

Comment 20

[Maxime Thirouin]

Is this normal I can't drag the window correctly now ? I've to use a 10px place in the top right of the chrome. So weird.

Comment 21

[Markus Stange [:mstange]]

No, it's not normal. Please file a new bug about the problem you're seeing.

Comment 22

[Maxime Thirouin]

Ok nevermind I were using the snippet below as user style

* {
    -moz-window-dragging: no-drag;
}

...
Sorry !

Comment 23

[Catalin Varga [QA][:VarCat]]

Verified as fixed using:

FF 35.0b8
Build Id: 20141229214612
Mac Os X 10.10