This is a regression from bug 508479 (based on regression date range and observed behavior). I was somewhat unpleasantly surprised by it when I updated, since now the only way to detach a tab is to drag it completely out of the window; in particular if the browser happens to be maximized there's no way to detach a tab at all.
also confirmed in 1.9.2 nightlies.
windows build is not working also Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2b2pre) Gecko/20091103 Namoroka/3.6b2pre ID:20091103045100 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091103 Minefield/3.7a1pre ID:20091103044839
Yeah, I know what caused this. Just updating my build and will upload a (hopefully) trivial patch.
Bring back the old behavior of nsContentAreaDragDrop, but don't dispatch non-prevented-drops to content.
No automatic tests for this, not at least today.
Comment on attachment 410028 [details] [diff] [review] patch Needs tests!
Attachment #410028 - Flags: superreview?(jonas) → superreview+
A bit hackish test, based on just the flags dragsession have.
Blocking on this blocker regression.
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2
Target Milestone: --- → mozilla1.9.2
Olli, are the tests complete then?
Target Milestone: mozilla1.9.2 → mozilla1.9.3a1
Some better tests would be good, but the tests I pushed do check for this particular regression.
Thanks so we are ok here. Also the following litmus test covers this particular issue: https://litmus.mozilla.org/show_test.cgi?id=9252
Verified fixed on the 1.9.2 branch using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b2pre) Gecko/20091106 Namoroka/3.6b2pre. Also checked equivalent builds on Windows 7, Windows Vista, Mac 10.4 and 10.5
Looks good on trunk too with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091106 Minefield/3.7a1pre ID:20091106102904 Fixing keyword...
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.