[10.10] Entire Firefox Window Draggable

VERIFIED FIXED in Firefox 35

Status

()

defect
VERIFIED FIXED
5 years ago
3 years ago

People

(Reporter: danne.da, Assigned: mstange)

Tracking

(Blocks 1 bug)

Trunk
mozilla35
x86
macOS
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify +

Firefox Tracking Flags

(firefox34 unaffected, firefox35 verified)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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.
(Reporter)

Updated

5 years ago
Depends on: 944836
(Assignee)

Comment 1

5 years ago
Uhhh that's bad. Are you using any kind of non-default theme?
Blocks: 944836
No longer depends on: 944836
(Reporter)

Comment 2

5 years ago
(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.
(Assignee)

Comment 3

5 years ago
OK, I see this on 10.10.
Assignee: nobody → mstange
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: Entire Firefox Window Draggable → [10.10] Entire Firefox Window Draggable
(Assignee)

Comment 4

5 years ago
Posted patch patchSplinter Review
And this is how we experience first-hand what we're getting ourselves into by using private APIs. :-)
Attachment #8492599 - Flags: review?(smichaud)

Updated

5 years ago
Duplicate of this bug: 1070454
(Assignee)

Updated

5 years ago
Duplicate of this bug: 1070478

Comment 7

5 years ago
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.
(Assignee)

Updated

5 years ago
Duplicate of this bug: 1070031
(Assignee)

Comment 9

5 years ago
I filed bug 1070710 with a window dragging implementation that does not rely on private APIs.
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.

Updated

5 years ago
Duplicate of this bug: 1070954

Comment 12

5 years ago
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 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.
Attachment #8492599 - Flags: review?(smichaud) → review+
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.
(Assignee)

Comment 15

5 years ago
(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.

Updated

5 years ago
Duplicate of this bug: 1070151
https://hg.mozilla.org/mozilla-central/rev/8f7dcbde58db
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35

Updated

5 years ago
Duplicate of this bug: 1071960

Comment 20

5 years ago
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.
(Assignee)

Comment 21

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

Comment 22

5 years ago
Ok nevermind I were using the snippet below as user style

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

...
Sorry !
Flags: qe-verify+
QA Contact: catalin.varga
Verified as fixed using:

FF 35.0b8
Build Id: 20141229214612
Mac Os X 10.10
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.