Closed
Bug 458070
Opened 17 years ago
Closed 17 years ago
Dragging a url to the tabbar loads it in multiple tabs
Categories
(Firefox :: Tabbed Browser, defect)
Firefox
Tabbed Browser
Tracking
()
VERIFIED
FIXED
Firefox 3.1b1
People
(Reporter: bzbarsky, Assigned: asaf)
References
Details
(Keywords: regression, verified1.9.1)
Attachments
(1 file)
|
1.92 KB,
patch
|
mconnor
:
review+
|
Details | Diff | Splinter Review |
BUILD: 2008-10-01 morning debug build
STEPS TO REPRODUCE:
1) Start the browser
2) Load http://www.mozilla.org/projects/minefield/
3) Make sure you have two tabs open
4) Focus the tab the load from step 2 happened in
5) Grab the lizard head icon in the url bar, drag it to the right-hand side of
the tabbar (to the right of both existing tabs), and drop it. Make sure to
not hover the existing tabs in the process.
EXPECTED RESULTS: New tab loads with the url
ACTUAL RESULTS: New tab loads with the url, but the url is also loaded in the existing tab focused in step 4.
NOTES: The same result obtains if dragging any link from the document to the right-hand side of the tabbar.
Pretty sure this is a regression.
Flags: blocking-firefox3.1?
Comment 1•17 years ago
|
||
I can't reproduce this ... but I'm not sure I've understood your
description.
I tested with today's Minefield nightly
(2008-10-01-02-mozilla-central) on OS X 10.5.5.
> but the url is also loaded in the existing tab focused in step 4
Don't you mean "reloaded" (since that tab already contained
http://www.mozilla.org/projects/minefield/, thanks to step 2)?
But I didn't see that tab reload, either.
Comment 2•17 years ago
|
||
I confirmed the issue in Windowx XP.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081001 Minefield/3.1b1pre
| Assignee | ||
Comment 3•17 years ago
|
||
Stopping propagation on the per-spec drop event doesn't stop the legacy draqdrop event. I'm not sure if this isn't something we should work around in gecko as well.
Updated•17 years ago
|
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Updated•17 years ago
|
Attachment #341432 -
Flags: review?(mconnor) → review+
Comment 4•17 years ago
|
||
I no longer see this with today's nightly..
Fixed with https://bugzilla.mozilla.org/show_bug.cgi?id=454324 ???
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20081006 Minefield/3.1b1pre ID:20081006034237
Comment 5•17 years ago
|
||
a=beltzner for beta 1 landing, see bug 458696 comment 5; bz's right, since we repaired the core code which caused the crash and are now using the new drag & drop API to do tag drag n' drop, we should make an effort to reduce regressions in that new path for beta.
Comment 6•17 years ago
|
||
Landed for b1 with a=beltzner
http://hg.mozilla.org/mozilla-central/rev/060b7352c2ad
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
OS: Mac OS X → All
Hardware: PC → All
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.1b1
| Assignee | ||
Comment 7•17 years ago
|
||
Thanks Gavin.
Updated•17 years ago
|
Version: unspecified → Trunk
Maybe this will help:
Also it seems that "draggesture" events can not be cancelled by event
listeners listening to "draggesture". (from Chrome/e.g. extensions)
Comment 10•17 years ago
|
||
verified fixed using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20081007 Minefield/3.1b1pre.
Status: RESOLVED → VERIFIED
Comment 11•17 years ago
|
||
Also verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.2) Gecko/2008091618 Firefox/3.0.2 ID:2008091618
Something we could cover with an automated test? Or shall we create a Litmus test for now?
Flags: in-testsuite?
Flags: in-litmus?
Comment 14•17 years ago
|
||
https://litmus.mozilla.org/show_test.cgi?id=7393 added to Litmus FFT.
Flags: in-litmus? → in-litmus+
Updated•17 years ago
|
Keywords: fixed1.9.1
Updated•17 years ago
|
Keywords: fixed1.9.1 → verified1.9.1
You need to log in
before you can comment on or make changes to this bug.
Description
•