Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090201 Shiretoko/3.1b3pre Ubiquity/0.1.5 ID:20090201020520 With the following steps the whole browser window is turned into a dragable unified window on OS X. Any other d&d event is absorbed. Steps: 1. Open the testcase 2. Open another tab via Cmd+T 3. Try to start a d&d action anywhere in the content or chrome area I'll try to find the regression window for that d&d problem.

This happened between 080601 and 080701. Means it regressed before the patch on bug 398928 was checked-in.

Sorry for the typing error. This regressed between 080711 and 080712. Check-ins within this time frame: http://tinyurl.com/d4mo4y I suspect this regressed by the patch on bug 435334. But it's still curious how it affects the handling of d&d events inside the browser.

It may also have existed before bug 435334, since that basically re-enabled Java. To get a true regression range, I think you'll need to do some ugly pull & build with the patch from bug 435334 and bisect that way. My instinct tells me that if you were to play with it around the date that Neil's drag-and-drop patch went in, you might find the regression there. Enn: have you had a chance to look at this? --> Core::Drag and Drop

> It may also have existed before bug 435334 It did ... or something very much like it. See bug 431902.

(In reply to comment #4) > It did ... or something very much like it. See bug 431902. Steven, any chance to get a tryserver build again with the patch attached on bug 431902? So we could see if it solves the problem or not.

(In reply to comment #5) Sure. But the patch is Leopard-specific. Do we know that this bug is Leopard-only?

I just tried and failed to repro this bug on OS X 10.4.11. Henrik, I'd appreciate it if you could confirm my results.

Using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b3pre) Gecko/20090131 Shiretoko/3.1b3pre I am not able to repro using the STR in Comment 0. The one thing that did happen on this machine is that I got an alert dialog indicating there was a Java exception of some sort.

> The one thing that did happen on this machine is that I got an alert > dialog indicating there was a Java exception of some sort. That's normal. The testcase has an empty APPLET tag.

By the way, we probably shouldn't block the 1.9.1 release for this. This bug appears to be a dup of bug 431902, and to have existed for a long time (possibly since the first Leopard release). Yet it hasn't often been reported, and seems to be quite seldom encountered. My patch for bug 431902 is pretty hacky ... even for me :-) So if we're going to use it, it needs to get into beta3 -- landing it in an RC would (I think) be too risky. But bug 431902 is so old that I've forgotten all the research I did for it, and would need to do it over again (I'd even forgotten that I had a patch at all). This probably isn't something that should be crammed into the few days we (presumably) have before the beta3 code freeze. If someone can come up with a better alternative, that's fine with me. But if this really is an OS bug (or partly/mostly an OS bug), I think that's unlikely.

Here's the true regression range for this bug: 2007-10-29-04-trunk 2007-10-30-04-trunk I'd guess the culprit is the patch for bug 303110 ("Add Unified Toolbar machinery to Cocoa widgets"), landed on 2007-10-29 21:03 (Pacific Time).

I've found that part of the bug 303110 patch does trigger this bug. I'm now trying to narrow that down.

I've confirmed that this is an Apple bug. The problem goes away when you comment out the following line at the beginning of [ToolbarWindow initWithContentRect:...]: aStyle = aStyle | NSTexturedBackgroundWindowMask; Apple's doc on NSTexturedBackgroundWindowMask (http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/doc/c_ref/NSTexturedBackgroundWindowMask) says: "The window displays with a metal-textured background. Additionally, the window may be moved by clicking and dragging anywhere in the window background. ..." All top-level browser windows are ToolbarWindows, and this doesn't normally make them draggable from everywhere in their content region. But somehow it's happening here -- which is the Apple bug. I'm not sure there's anything we can do about this aside from my patch for bug 431902. I'll start digging again tomorrow.

> The problem goes away when you comment out the following line at the > beginning of [ToolbarWindow initWithContentRect:...]: In nsCocoaWindow.mm.

(In reply to comment #13) > All top-level browser windows are ToolbarWindows, and this doesn't > normally make them draggable from everywhere in their content region. Because we return NO in [ChildView mouseDownCanMoveWindow].

Here's another patch that's simpler and much less indirect (more precisely targeted) than my patch for bug 431902. Thanks, Markus, for the hint about mouseDownCanMoveWindow! Though I'm quite confident this patch should work and be trouble-free, I still think it should get into beta3 (instead of an RC). A tryserver build will follow in a while.

Here's the tryserver build: https://build.mozilla.org/tryserver-builds/2009-02-03_14:29-smichaud@pobox.com-bugzilla476393/smichaud@pobox.com-bugzilla476393-firefox-try-mac.dmg

This build is working fine. Thanks Steven!

Landed on mozilla-central: http://hg.mozilla.org/mozilla-central/rev/52471722f252

Landed on the 1.9.1 branch: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/bf9dc616b0a9

Verified fixed on trunk and branch with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090208 Minefield/3.2a1pre Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090208 Shiretoko/3.1b3pre