User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090123 Shiretoko/3.1b3pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090123 Shiretoko/3.1b3pre The "New Tab" button used to be a drag and drop zone just like the "New Window" button still is. The code for this has been removed when the new "New Tab" button on the tab-bar was introduced and hasn't been re-added since. It used to be possible to drag just about everything on the button and it would open in a new tab: bookmarks, text-urls, urls, pictures, currently open tabs (which would then be duplicated in a new tab) or even simple text (which would result in an "I'm feeling lucky" search). This excellent feature has been introduced in Firefox 1.5 and was fully functional until the recent "New Tab"-button redesign. It is still possible with the "New Window" button but impossible with both the "New Tab"-button on the tab-bar and the recently re-added custom "New Tab" button. It should be fully functional for ALL THREE buttons. In order to actually be fully functional with the new "New Tab" button on the tab-bar not only has the old code to be re-added to the button, it also has to be slightly redesigned since it is much too small to be usable as a drop zone in case of overflow. And consistent size without shrinking it in case of overflow would solve this problem. Reproducible: Always Steps to Reproduce: 1. Drop anything (bookmark, url, text, open tab) onto either of the two "New Tab" Buttons 2. Drop anything (bookmark, url, text, open tab) onto the "New Window" button Actual Results: 1. A "forbidden" icon appears when trying to drop anything on the "New Tab" button in the "Navigation Toolbar". The current tab is moved next to the "New Tab" button on the tab-bar instead of being duplicated (it's just like the button isn't there but as if something is simply dropped onto the tab-bar itself). 2. Everything is functioning they way it should with all three buttons Expected Results: Firefox should attempt to open anything dropped on either of these buttons in a new tab. A currently opened tab dropped onto either of the buttons should be duplicated in a new tab.

All this behavior works fine for me on the old button, the one on the tabbar works simply because the whole tabbar is a drop zone.

Natch, which build are you using? 1. The recently re-added "old-stlye" button does certainly NOT work as a drop-zone on Gecko/20090123 Shiretoko/3.1b3pre on Windows while the "New Window" drop-zone still works fine as it used to. 2. "the one on the tabbar" does NOT work for tab-duplication (the tab is simply moved next to it) and at least shows rather ugly and unexpected visuals for all other cases where the button doesn't work as a drop-zone but the whole tab-bar below does. The drop-zone code has to be re-added to both versions of the button in order to restore established features and functionality.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090127 Shiretoko/3.1b3pre Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090123 Minefield/3.2a1pre For the old customizable button I can drop tabs/images/links etc. and I get the same behavior as in 3.0 (on 3.1 Branch there's no status bar text and no tooltips due to the missed stripng freeze). Concerning *this* behavior, do you see anything different?

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090127 Shiretoko/3.1b3pre I see a VERY different and a very wrong behaviour. For "New Tab"-"button classic" in the Navigation toolbar I do NOT have any drop-zone at all. The result would be identical to trying to drop something on e.g. the "reload" button ... a "forbidden" icon appears and nothing happens at all. Trying to drop an open tab onto the "classic" "New Tab" button doesn't duplicate it like it should, it actually detaches it. I just tried with a clean profile on the above version of Shiretoko in a virtual machine and the behavior is unchanged. Quite honestly, I'm a little surprised that it works for you ... (maybe it has to do with Minefield or maybe you have an extension installed that brings the "classic" button back completely?). For me it is clearly broken while the "New Window" button still works perfectly fine ...

Where do you place the new tab button? Note: the new tab customizable button was brought *back* now in 3.1, the code hasn't changed at all, so unless there's some tab dnd interfering, it should work the same as before, hence the question: where do you place it exactly?

I'm perfectly aware of the fact that the "classic" button was brought back. In the redesign there was a code cleanup, the old drop-zone-code was inexplicably removed and it appears that it hasn't been re-added when the button was brought back. I just confirmed again on an absolutely clean installation of: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090127 Shiretoko/3.1b3pre in VirtualBox. 1. Add the "New Tab" button to the top left of the "Navigation Toolbar" (or quite frankly anywhere else, I moved it around like crazy, it does not matter the slightest). 2. Drag anything onto the button 3. A "forbidden" icon appears, nothing happens 4. Do the same with the "New Window" button 5. Everything works fine for this button ... I'm sure it's broken. I have no idea why it isn't for you, please try on a clean Shiretoko-Setup (or an upgrade from Firefox 3.0.x) with a clean profile, but I'm confident that it will not work for you. I have not tested Minefield but this bug is about Shiretoko.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090127 Shiretoko/3.1b3pre Confirmed. It may be due to some patch not being checked in to 3.1 yet, investigating...

This is due to the fact that we don't define an ondragover/exit function in 3.1.

This has been a feature since Firefox 1.5 and it still works for the for the "New Window" button. This was an excellent, easy to use, intuitive and powerful feature that made the button more powerful than on any other browser. I strongly believe that this should be blocking 3.1 and that it should be fully functional for ALL instances of the "New Tab" button, including the new, redesigned one on the tab-bar! It also should be a relevant factor in the design of the new button. Alex Faaborg, maybe unaware of this feature, completely ignored it in his proposed design in https://bugzilla.mozilla.org/show_bug.cgi?id=457651 A width of 18px in case of overflow is simply much too small for a drop-zone, the button should keep its regular size of 32px in every possible scenario.

Can we leave this bug to the regression, namely the fact that the old customizable button doesn't accept drops? Your problem has been brought up before, and it was decided that 18px for the overflow button is enough. If you would rather extend this bug, I can file a new one for this particular regression, which IMHO should block beta 3.

I'll stop complaining about the 18px if that's what it takes (although I still believe that the decision was wrong and this important and well-established feature was completely ignored when the decision was made) but it would be wrong to ship 3.1 with two entirely different "New Tab" buttons with entirely different features and behavior. If you would like to file a separate bug to restore the functionality exclusively to the old, customizable button you are welcome to do so. When dropping something onto the "New Tab" button the user should expect the same behavior, no matter which version of the "New Tab" he/she is using. It would be wrong to restore it to only one of the buttons.

Comment on attachment 359151 [details] [diff] [review] fix <gavin> Natch: I don't see where onDragOver would actually be called... <gavin> Natch: and won't this be fixed when we take the strings from 456984? <Natch> gavin: heh, forgot to add that in the patch <Natch> gavin: yes it will <gavin> Natch: we should file a followup on landing those strings, and mark it blocking RC1

So this gets fixed by bug 474917?

yeah

Comment on attachment 359151 [details] [diff] [review] fix Gavin, should we take this patch in the interim? It's a fairly safe patch and doesn't contain any of the l10n changes that are problematic this far in the cycle.

Comment on attachment 359151 [details] [diff] [review] fix Uhm, meant to update this first. I'll attach a new patch with the handler *actually* being called.

Depends whether we care about this being fixed in 3.1 beta 3 or not. If we don't it will be fixed before the next milestone by bug 474917, so no point in rushing it. I guess I don't have strong feelings either way.

Comment on attachment 362802 [details] [diff] [review] take 2 Let's just wait until bug 474917 lands.

Maybe some tests should be added here though. /me wanders off to browser-chrome land

If there's more work here, please file a new bug for tests.

Verified fixed on trunk with builds on OS X and Windows: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090301 Minefield/3.2a1pre ID:20090301020403

The mozilla-1.9.1 tree is open for string changes again. Please make sure the bug stays marked as latel10n, and check in when the tree is green!

Verified fixed on 1.9.1 with builds on OS X and Windows: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090309 Shiretoko/3.1b4pre ID:20090309020654 Nochum, do you have made any progress with an automated test yet?

I'll try to take car of that in bug 475203 (together with the other tests there).

This problem appear to be fixed for ONE OF THE TWO "new tab" buttons in the current branch builds: the classic one in the toolbar. So I guess this technically fixes the regression. That still leaves the new "new tab" in the tab-bar without a proper dropzone, making it behave significantly different to certain events than when performing the same action with the classic toolbar-button. Just try dropping a currently open tab on both buttons: The classic button correctly duplicates it, the new button ... well, the tab is simply moved next to it which doesn't make much sense. Do I have to file a new bug for this or can we address this as well?

File a new bug, please. I'm not sure I agree that the tabbar new tab button should have the same behavior, though, since the chances of accidentally dragging something to the wrong place is much greater.

Filed bug 486202 on trying to get a test for this, as of now that doesn't seem possible (mostly due to the fact that the new tab button isn't part of the default buttons on the toolbar).