Closed
Bug 465184
Opened 16 years ago
Closed 15 years ago
Dropping a tab on itself shouldn't detach it
Categories
(Firefox :: Tabbed Browser, defect, P1)
Firefox
Tabbed Browser
Tracking
()
VERIFIED
FIXED
Firefox 3.5
People
(Reporter: sylvain.pasche, Assigned: asaf)
References
Details
(Keywords: regression, verified1.9.1, Whiteboard: [fixed by bug 471499])
Attachments
(3 files, 5 obsolete files)
1.14 KB,
patch
|
asaf
:
review-
|
Details | Diff | Splinter Review |
18.23 KB,
patch
|
asaf
:
review-
|
Details | Diff | Splinter Review |
395 bytes,
text/plain
|
Details |
I found no way to cancel detaching a tab once the drag operation started. If a tab is dragged by error, I would expect that dropping it on itself cancels the operation. Pressing the Esc key should also cancel it.
Comment 1•16 years ago
|
||
1. Drag tab off the window 2. Drag the new tab back on the old windows tab bar Does this not work for you or did you mean something else? The Esc key doesn't seem very intuitive to me, but I guess some sort of keyboard shortcut might be good :/.
Reporter | ||
Comment 2•16 years ago
|
||
Yes, it works if the detached tab is dropped on the tab bar just before or after the current tab (when you see the arrow icon indicating that you want to move the tab). However if you drop the tab on itself, it will open a new window. That could be the intended behavior, however if you want to select a tab and unintentionally drag it, it will open in a new window which could be confusing. The Esc key is the common way of canceling a dragging operation on the three platforms if I'm correct. So I think it should be intuitive.
Updated•16 years ago
|
Flags: blocking-firefox3.1?
OS: Mac OS X → All
Hardware: PC → All
Summary: Unable to cancel detaching a tab → Dropping a tab on itself shouldn't detach it
Assignee | ||
Comment 3•16 years ago
|
||
Please open a new bug for the ESC issue. The dragging-on-itself issue is fixed.
Assignee: nobody → mano
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 4•16 years ago
|
||
Thanks. I filed bug 465608 for that.
Comment 5•16 years ago
|
||
(In reply to comment #3) > Please open a new bug for the ESC issue. The dragging-on-itself issue is > fixed. Are you sure ? I'm still seeing this Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081118 Minefield/3.1b2pre ID:20081118125341
Assignee | ||
Comment 6•16 years ago
|
||
By "itself" i mean on the actual tab element, that works on mac, at least for me.
Comment 7•16 years ago
|
||
yeah, so do I repro: grab a tab "element" move it left/right a few px (stay with the pointer well inside the "element") result: it detaches and opens in a new window
It's worse than that. Dropping a tab anywhere on the browser window, when the "don't" mouse pointer shows, causes the tab to be detached. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081118 Minefield/3.1b2pre ID:20081118181119 Definitely not fixed. Please reopen.
Comment 9•16 years ago
|
||
As of the build: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b2pre) Gecko/20081119 Minefield/3.1b2pre ID:20081119041246 This isn't fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 10•16 years ago
|
||
It appears the only way to cancel the taer-off is to insert the tab at a different position on the tabbar. Of course now you have to move it again to restore the original order.
Comment 11•16 years ago
|
||
The problem which was fixed is the issue raised in comment #7, which is NOT the original issue in this bug.
Comment 12•16 years ago
|
||
(In reply to comment #11) > The problem which was fixed is the issue raised in comment #7, which is NOT the > original issue in this bug. Comment # 7 was NOT fixed as best as of: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b2pre) Gecko/20081119 Minefield/3.1b2pre ID:20081119041246 Original issue regardless.
Comment 13•16 years ago
|
||
(In reply to comment #11) > The problem which was fixed is the issue raised in comment #7, which is NOT the > original issue in this bug. hmm, comment 7 is not fixed, at least not on windows. There is no way to prevent the tab from detaching.
Comment 14•16 years ago
|
||
HMm guess you are correct. I thought that part was at least fixed.
Comment 15•16 years ago
|
||
As a workaround of this issue, I think the following patch to fix this issue. --- orig/tabbrowser.xml 2008-11-19 13:54:04.000000000 +0900 +++ new/tabbrowser.xml 2008-11-20 08:23:46.052296000 +0900 @@ -2203,17 +2203,28 @@ // This does not work at all (see bug 458613) var target = aEvent.relatedTarget; while (target && (target != this && target != gNavToolbox)) target = target.parentNode; if (target) return; this.mTabDropIndicatorBar.collapsed = true; + + //If dragging/dragleave within tab, + //_draggingOnItself must not be reset to + //prevent it from detaching a tab. + var target = aEvent.originalTarget; + while(target){ + if (target.localName == 'tab') + break; + target = target.parentNode; + } + if (!target) this._draggingOnItself = false; + aEvent.stopPropagation(); ]]> </body> </method> <method name="moveTabTo"> <parameter name="aTab"/> <parameter name="aIndex"/>
Reporter | ||
Comment 16•16 years ago
|
||
Could you please attach this patch to the bug and ask mano@mozilla.com for review? Some drive-by nits: put a space after "//" and add space after operators or around braces ("while (foo) {" instead of "while(foo){").
Comment 17•16 years ago
|
||
Sorry, I am not familiar about the source tree. I ask a person knowing it well.
Comment 18•16 years ago
|
||
this sounds easier and works fine.
Attachment #349398 -
Flags: review?(mano)
Comment 19•16 years ago
|
||
_draggedTab name was confusing with current local draggedTag var. Actually we could also discard draggingOnItself completely, and use only this var, on dragend we could compare the tab we are trying to detach with the active tab for the current active browser window, since initing a drag focuses the tab.
Attachment #349398 -
Attachment is obsolete: true
Attachment #349406 -
Flags: review?(mano)
Attachment #349398 -
Flags: review?(mano)
Assignee | ||
Comment 20•16 years ago
|
||
Comment on attachment 349406 [details] [diff] [review] patch v1.1 r=mano
Attachment #349406 -
Flags: review?(mano)
Attachment #349406 -
Flags: review+
Attachment #349406 -
Flags: approval1.9.1b2?
Updated•16 years ago
|
Assignee: mano → mak77
Comment 21•16 years ago
|
||
mh, i found an error :\ (event -> aEvent) and that has some strange behaviour. looking at it now
Updated•16 years ago
|
Attachment #349406 -
Attachment is obsolete: true
Attachment #349406 -
Flags: approval1.9.1b2?
Comment 22•16 years ago
|
||
Comment on attachment 349406 [details] [diff] [review] patch v1.1 ok there is definately something bad, the tab we leave before dragend happens is not the same we started dragging, so this actually doesn't work.
Comment 23•16 years ago
|
||
well really what happens is that when you complete a drag, before dragend is called we receive a dragleave event about us leaving the node we are over, and since relatedTarget is not set due to bug 458613 we can't detect correctly why leave has been called, so every check to clear draggingOnItself does not make sense.
Comment 24•16 years ago
|
||
this is practically an half way between my patch and Alice's idea, this code should be revised once d&d issues have been fixed. Sorry for double work.
Attachment #349425 -
Flags: review?(mano)
Comment 25•16 years ago
|
||
This definitely blocks. It's also part of the solution posited in bug 465346, though I think we should leave the two bugs separate :)
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Target Milestone: --- → Firefox 3.1
Updated•16 years ago
|
Status: REOPENED → ASSIGNED
Keywords: regression
Comment 27•16 years ago
|
||
Feel free to ignore this suggestion, but doesn't it seem logical that a new tab opens if the tab is dragged outside the window or another location, because it seems to me that dragging it into the main window or the toolbar doesn't seem very intuitive. Perhaps a specific location in the window that achieves this function?
Comment 28•16 years ago
|
||
(In reply to comment #27) > Feel free to ignore this suggestion, but doesn't it seem logical that a new tab > opens if the tab is dragged outside the window or another location, because it > seems to me that dragging it into the main window or the toolbar doesn't seem > very intuitive. Perhaps a specific location in the window that achieves this > function? I agree with this. Is is counter to the design of the entire operating system. Dragging something fro the application to the desktop should either do nothing or add something to the desktop. The 2 things that might make sense for dragging a tab to the desktop would either be to crate a link to the URL on the desktop or do a save of the page to the desktop. Opening the contents of the tab in another window of the same application is just counter to the entire Operating System UI design.
Comment 29•16 years ago
|
||
(In reply to comment #27) > Feel free to ignore this suggestion, but doesn't it seem logical that a new tab > opens if the tab is dragged outside the window or another location, because it Yes, well, that's why dragging a tab outside of the window will spawn a new window. > very intuitive. Perhaps a specific location in the window that achieves this > function? No, we don't need to add new targets. The primary interaction will be "drag a tab off the tabstrip and it becomes a new window". What we need to do is ensure that through cursor feedback we make it clear what we determine to be "off the tabstrip".
Keywords: regression
Comment 30•16 years ago
|
||
fair enough, although once this function is working, I feel that certain locations on screen, intuitively, should not open a new tab. For example. dragging a tab onto the bookmarks toolbar does not seem to achieve the required function. There should be certain onscreen locations that achieve different functions, rather than a blanket, open in new window if the tab is dragged.
Comment 31•16 years ago
|
||
(In reply to comment #30) > fair enough, although once this function is working, I feel that certain > locations on screen, intuitively, should not open a new tab. For example. > dragging a tab onto the bookmarks toolbar does not seem to achieve the required > function. There should be certain onscreen locations that achieve different > functions, rather than a blanket, open in new window if the tab is dragged. Please see bug 465332 and bug 465910
Updated•16 years ago
|
Keywords: regression
Comment 33•16 years ago
|
||
(In reply to comment #29) > No, we don't need to add new targets. The primary interaction will be "drag a > tab off the tabstrip and it becomes a new window". What we need to do is ensure > that through cursor feedback we make it clear what we determine to be "off the > tabstrip". Can we make the drag-drop movement more distinct, e.g. something like "tab must be dropped at least xx pixels outside the tab strip for it to count as a new window action"? Right now theoretically just a one pixel drag-drop is needed (if you drag the bottom pixel of the tab and drop it on the content area) to spawn a new window, and there's often no visual indication of what happened -- all of a sudden you're looking at a window with just one tab, making it look like you just lost all other tabs. I have no quantifiable data to back this up yet since SUMO visitors rarely use betas, but I feel that this could become a common, confusing problem for people.
Comment 34•16 years ago
|
||
David, the patch here helps a lot, actually detach is a pain since a few pixels are enough to detach, with this patched you cannot detach on itself and a few pixels above the tabbar. hwv what you're asking is bug 465346.
Comment 35•16 years ago
|
||
Marco why not to use in _setEffectAllowedForDataTransfer if (sourceNode == aEvent.target) { this._draggingOnItself = true; return dt.effectAllowed = "none"; } then we not need this._currentDraggedTab at all
Comment 36•16 years ago
|
||
(In reply to comment #35) > Marco > why not to use in _setEffectAllowedForDataTransfer > > if (sourceNode == aEvent.target) { > this._draggingOnItself = true; > return dt.effectAllowed = "none"; > } yeah could work, hwv i think Mano is working on a new patch to solve major complaints and original version with coordinates check could be used to implement a treshold, so i'm even not sure if this patch needs to exist at all.
Comment 38•16 years ago
|
||
I'm rather amazed this hasn't been addressed in the 3.1b2 build released today. This bug is infuriating. I've only run into it about 50 times this morning just trying to switch from one tab to another. Drag-and-drop should have been left out of this release until this issue had been resolved.
Comment 39•16 years ago
|
||
(In reply to comment #38) > I'm rather amazed this hasn't been addressed in the 3.1b2 build released today. > This bug is infuriating. I've only run into it about 50 times this morning just > trying to switch from one tab to another. Drag-and-drop should have been left > out of this release until this issue had been resolved. You probably don't see this bug but rather bug 465346.
Comment 40•16 years ago
|
||
A new window with the dragged tab should only be created when the tab is dragged outside the current window (not just when it has moved some pixels...). Within the current window, dragging means re-order tabs or moving the page into the bookmarks toolbar.
Comment 41•16 years ago
|
||
i'm attaching this minimal patch hoping we can take it while waiting for a new tab detach version
Attachment #349425 -
Attachment is obsolete: true
Attachment #349425 -
Flags: review?(mano)
Comment 42•16 years ago
|
||
check this...... adding new flavour application/x-moz-tabbrowser-tab-url to hold url from drag tab.
Comment 43•16 years ago
|
||
unassigning from me, minimal patch is there but we still need relatedTarget to make things working correctly and i don't know the status of fixes from other devs, so there's nothing more i can do actually.
Assignee: mak77 → nobody
Status: ASSIGNED → NEW
Comment 44•16 years ago
|
||
Attachment #352547 -
Attachment is obsolete: true
Attachment #352609 -
Flags: review?(mano)
Comment 45•16 years ago
|
||
Echoing comment #40: I am being driven crazy by all the accidental new windows I am creating in 3.1b2. Call me sloppy with the mouse, but an accidental drag on a tab slings it off into a new window. Tab should have to be dragged beyond the window before a new window is generated. Looked for config setting I could disable, haven't yet found it.
Comment 46•16 years ago
|
||
I disagree that the tab should be dragged outside the window to detach. I believe the best scenario is to simply drag the tab fully below the tabbar, and into the web content area--obvious exceptions for where the drop is in a textarea. Why? Consider what happens when a window is maximized. We shouldn't need to resize the window just to detach a tab. The other benefit is that the motion to detach is relatively minimal but also avoids accidental detach. Why have to drag a tab way across a screen or resize or relocate a browser window just to detach a tab.
Comment 47•16 years ago
|
||
Just as a thought, not sure whether its possible to implement as such, but it seems that what is currently done is a blanket, if tab moved then detach. But considering the actual content of a Firefox browser's layout, it seems logical then that rather than a blanket when moved, detach, it would be far simpler to say, when moved into content panel (/ outside of window), detach. Looking at the contents of the toolbar, dragging onto 75% of the content up there should not detach, but perform another function, i.e. bookmarks should add new bookmark, address bar should copy URL, tab bar reorders... etc. This would seem to fix this bug, and seems to be more logical, at least to me, and even, less bug prone. Even looking at moving a tab outside a window, though I feel I'm deviating from the topic of this bug slightly, should probably create a URL in that location, but that's rather an afterthought, so i feel that the way this feature is being implemented may need a rethink.
Comment 48•16 years ago
|
||
Start thinking on the 'use case': when would an user really would like to drag the tab to create a new window? Or even more simple: why/when would an user really want to create a new window with the tab? Possible scenario: drag the tag with Google Calendar outside FF, to create a 'Google Calendar' application window (Prism?). Dragging a tab to content space is precisely what is happening to all those people accidentally dragging the tab... Dragging a tab onto the desktop is not about creating an URL (for me, a tab is an opened web page/application), but creating a window with that open web page/application. Dragging a bookmark should create an URL.
Comment 49•16 years ago
|
||
Can we get a tryserver with this patch applied?
Comment 50•16 years ago
|
||
I tried to get a tryserver build, but for some reason the patch didn't apply, while it does in my local tree.
Comment 51•16 years ago
|
||
Yeah. Same happens for me. Looks like it has been bitrotted. Here the brief log: http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1229549482.1229550051.23916.gz patching file browser/base/content/browser.js Hunk #1 FAILED at 2661. Hunk #2 FAILED at 2718. Hunk #3 FAILED at 2755. Hunk #4 FAILED at 2794. Hunk #5 FAILED at 4971. Hunk #6 FAILED at 5005. 6 out of 6 hunks FAILED -- saving rejects to file browser/base/content/browser.js.rej patching file browser/base/content/browser.xul Hunk #1 succeeded at 339 (offset -1 lines). patching file browser/base/content/tabbrowser.xml patching file browser/components/places/content/controller.js Hunk #1 FAILED at 1331. Hunk #2 FAILED at 1486. 2 out of 2 hunks FAILED -- saving rejects to file browser/components/places/content/controller.js.rej patching file browser/components/places/content/utils.js patching file toolkit/components/places/src/utils.js Hunk #1 FAILED at 80. 1 out of 2 hunks FAILED -- saving rejects to file toolkit/components/places/src/utils.js.rej patching file toolkit/content/nsDragAndDrop.js Hunk #1 FAILED at 290. 1 out of 2 hunks FAILED -- saving rejects to file toolkit/content/nsDragAndDrop.js.rej
Comment 52•15 years ago
|
||
I removed the DOS the line endings from the above patch so that it applies correctly.
Comment 53•15 years ago
|
||
(In reply to comment #52) > Created an attachment (id=354397) [details] > patch v1 - with line endings fixed Linux and Windows builds that include this patch (among others) are available at http://www.wg9s.com/ Perhaps we can get someone to do tryserver builds again?
Comment 54•15 years ago
|
||
(In reply to comment #53) > (In reply to comment #52) > > Created an attachment (id=354397) [details] [details] > > patch v1 - with line endings fixed > > Linux and Windows builds that include this patch (among others) are available > at http://www.wg9s.com/ Oops! I meant to say http://www.wg9s.com/mozilla/firefox/
Updated•15 years ago
|
Attachment #352609 -
Attachment is obsolete: true
Attachment #352609 -
Flags: review?(mano)
Updated•15 years ago
|
Attachment #354397 -
Flags: review?(mano)
Comment 55•15 years ago
|
||
Updating dependency, the patch here fixes all those bugs. Thanks Bill!
Comment 56•15 years ago
|
||
Ok, now everything works. Tryserver builds will appear here in some minutes: https://build.mozilla.org/tryserver-builds/2008-12-24_14:16-mozilla@hskupin.info-bug465184/
Comment 57•15 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081224 Minefield/3.2a1pre ID:20081224142958 with the tryserver build nothing in the errorconsole and this bug and dependencies are fixed bug 465184 = FIXED bug 465332 = FIXED bug 465910 = FIXED bug 467376 = FIXED bug 468553 = FIXED
Comment 58•15 years ago
|
||
Seeing the amount of responses we should handle this bug with a higher severity. Thanks Bill for the patch. Looks like we are fine and have to wait for the review of Mano.
Assignee: nobody → bill
Severity: normal → major
Status: NEW → ASSIGNED
Comment 59•15 years ago
|
||
Well I didn't really write the patch. I just took the patch from onemen.one@gmail.com and removed some stray carriage returns form the end of some of the lines.
Comment 61•15 years ago
|
||
(In reply to comment #57) > with the tryserver build nothing in the errorconsole and this bug and > dependencies are fixed > > bug 467376 = FIXED Incorrect. Bug 467376 is NOT fixed.
Comment 62•15 years ago
|
||
(In reply to comment #61) > (In reply to comment #57) > > with the tryserver build nothing in the errorconsole and this bug and > > dependencies are fixed > > > > bug 467376 = FIXED > > Incorrect. Bug 467376 is NOT fixed. Confirmed using provided try server builds, this bug does not appear to be fixed with this patch.
Comment 63•15 years ago
|
||
(In reply to comment #61) > (In reply to comment #57) > > with the tryserver build nothing in the errorconsole and this bug and > > dependencies are fixed > > > > bug 467376 = FIXED > > Incorrect. Bug 467376 is NOT fixed. My bad, i tested wrong. also, in the tryserver build RSS feeds are broken (missing stylesheet), don't know if that's related
Comment 64•15 years ago
|
||
(In reply to comment #63) > also, in the tryserver build RSS feeds are broken (missing stylesheet), don't > know if that's related That's another issue. Meanwhile you have already filed bug 471108 on that.
Assignee | ||
Comment 65•15 years ago
|
||
First, many thanks for your hard work on this. Since I don't like all this x-moz-tabbrowser-tab-url approach (and since i've a better fix for these issues), the patch here should fix just this bug. Please do that and I'll review it ASAP. Thanks.
Assignee | ||
Updated•15 years ago
|
Attachment #354397 -
Flags: review?(mano) → review-
Comment 66•15 years ago
|
||
(In reply to comment #65) > First, many thanks for your hard work on this. Since I don't like all this > x-moz-tabbrowser-tab-url approach (and since i've a better fix for these > issues), the patch here should fix just this bug. Please do that and I'll > review it ASAP. Thanks. Something like Marco's minimal patch from comment #41?
Assignee | ||
Comment 67•15 years ago
|
||
Yes, as long as that fixes the issue as described.
Comment 68•15 years ago
|
||
(In reply to comment #65) > First, many thanks for your hard work on this. Since I don't like all this > x-moz-tabbrowser-tab-url approach (and since i've a better fix for these > issues), the patch here should fix just this bug. Please do that and I'll > review it ASAP. Thanks. My personal opinion (which does not count for much) is that there are 3 choices here: 1. Your better fix for these issues needs to be included in beta3. 2. There needs to be a beta4. 3. The entire tear-off-tabs feature needs to be backed out and delayed until Firefox 3.2.
Comment 69•15 years ago
|
||
(In reply to comment #68) > My personal opinion (which does not count for much) is that there are 3 choices > here: > > 1. Your better fix for these issues needs to be included in beta3. > > 2. There needs to be a beta4. > > 3. The entire tear-off-tabs feature needs to be backed out and delayed until > Firefox 3.2. And #4. Rework the original tear-off patch to make the tear-off target very specific, instead of making it effective for every tab drag operation.
Comment 70•15 years ago
|
||
You can't choose 4 times, so they are actually 4 options to choose between. So 1 choice.
Comment 71•15 years ago
|
||
Can I a number one with fries?
Comment 72•15 years ago
|
||
OK sorry I made the comment that sparked all this bugspam
Comment 73•15 years ago
|
||
(In reply to comment #68) > My personal opinion (which does not count for much) is that there are 3 choices > here: > > 1. Your better fix for these issues needs to be included in beta3. > > 2. There needs to be a beta4. > > 3. The entire tear-off-tabs feature needs to be backed out and delayed until > Firefox 3.2. This was a pretty stupid comment for a number of reasons. This bug is not really the correct forum for me to be expressing my concerns of your fix not making beta3. Also, if I had bothered to check before commenting, I would have noticed that the beta3 code freeze date was pushed out an additional week so my concern was unfounded. In any event, in order to further this bug along, I have included the minimal patch from comment #41 in my Windows and Linux builds which are available here: http://www.wg9x.com/mozilla/firefox/ My preliminary testing indicates the patch does resolve the issue described in this bug.
Comment 74•15 years ago
|
||
The link is not working
Comment 75•15 years ago
|
||
Sorry: http://www.wg9s.com/mozilla/firefox/
Comment 76•15 years ago
|
||
In that case, maybe Marco would like to request mano's review on the minimal patch in comment 41? (Unless mano would like to pick it up himself...?)
Comment 77•15 years ago
|
||
Please stop fighting, and apply the 'minimal patch' to remove the frustration of a lot of people, and then start working on the 'ideal patch'(in a separate bug?).
Comment 78•15 years ago
|
||
Comment 35 should be addressed before attachment 352341 [details] [diff] [review] is chosen.
Comment 79•15 years ago
|
||
Comment 35 is about making a better patch, not about introducing a new problem caused by the 'minimal patch'. The 'minimal patch' is still valid as a quickfix to a very annoying problem.
Comment 80•15 years ago
|
||
(In reply to comment #79) > Comment 35 is about making a better patch ... Yes, and generally patches have to be made better before they will get reviewed and checked in - "valid" isn't good enough. Quick fixes to remove annoyances for nightly users are not usually the way things work. If you want the quick fix for yourself, download one of the builds linked above. Sorry for adding more to the noise. Let's all just keep quiet unless we are actually going to take ownership of a patch and get it reviewed.
Updated•15 years ago
|
Priority: -- → P1
Comment 82•15 years ago
|
||
Comment on attachment 352341 [details] [diff] [review] minimal patch seeing Mano is still working on its patch to address regressions, retrying with review. would be cool to be able to fix at least this bad behaviour for 3.1b3. relatedTarget fix did not help at all (and i still see relatedTarget as null).
Attachment #352341 -
Flags: review?(mano)
Comment 83•15 years ago
|
||
(In reply to comment #78) > Comment 35 should be addressed before attachment 352341 [details] [diff] [review] is chosen. I think the fact that the person who made comment #35 used the code from attachment 352341 [details] [diff] [review] in the patch they subsequently submitted kind of speaks to this issue.
Comment 84•15 years ago
|
||
Btw, comment 35 is about another (previous) patch, not the one i'm asking review on. That is a change based on Alice's idea, and is still working, that's not wrong, nor a quick fix just to workaround something to make happy nightly users. It is one of the possible checks we could do there, clearly anyone can come with a better idea, but after a month i can't see any new one.
Comment 85•15 years ago
|
||
this isn't really assigned to anyone atm, until we got an answer from Mano on current status of his new patch or review of mine.
Assignee: onemen.one → nobody
Updated•15 years ago
|
Status: ASSIGNED → NEW
Comment 86•15 years ago
|
||
(In reply to comment #85) > this isn't really assigned to anyone atm, until we got an answer from Mano on > current status of his new patch or review of mine. Don't do that. This bug will be fixed by Mano's patch in bug 471499. He may or may not be incorporating some of your patch. He's available on IRC pretty frequently.
Assignee: nobody → mano
Assignee | ||
Updated•15 years ago
|
Whiteboard: [patch on bug 471499]
Assignee | ||
Comment 87•15 years ago
|
||
Comment on attachment 352341 [details] [diff] [review] minimal patch See the other bug.
Attachment #352341 -
Flags: review?(mano) → review-
Comment 88•15 years ago
|
||
Fixed by bug 471499
Status: NEW → RESOLVED
Closed: 16 years ago → 15 years ago
Resolution: --- → FIXED
Updated•15 years ago
|
Keywords: fixed1.9.1
Comment 89•15 years ago
|
||
Verified on trunk and 1.9.1 with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090125 Shiretoko/3.1b3pre (.NET CLR 3.5.30729) ID:20090125052901 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090126 Shiretoko/3.1b3pre Ubiquity/0.1.5 ID:20090126020313 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090125 Minefield/3.2a1pre ID:20090125034316 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090126 Minefield/3.2a1pre ID:20090126020316
Status: RESOLVED → VERIFIED
Flags: in-litmus?
Keywords: fixed1.9.1 → verified1.9.1
Whiteboard: [patch on bug 471499] → [fixed by bug 471499]
Comment 90•15 years ago
|
||
I still have this problem with the last nightly under WinXP (1.9.1b3pre).
Comment 91•15 years ago
|
||
(In reply to comment #90) I don't have XP, but under 32bit Vista with the 1/28/09 build of 3.1b3pre, this bug is not present.
Comment 92•15 years ago
|
||
(In reply to comment #90) > I still have this problem with the last nightly under WinXP (1.9.1b3pre). Dragging a tab over itself shows me the invalid drop target icon. I cannot drop the tab on itself with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090129 Shiretoko/3.1b3pre (.NET CLR 3.5.30729) ID:20090129035313
Updated•15 years ago
|
Target Milestone: Firefox 3.1 → Firefox 3.5
Comment 94•14 years ago
|
||
Attachment #476887 -
Flags: review?
Updated•14 years ago
|
Attachment #476887 -
Flags: review? → review?(mevans4900)
You need to log in
before you can comment on or make changes to this bug.
Description
•