Closed Bug 465184 Opened 11 years ago Closed 11 years ago

Dropping a tab on itself shouldn't detach it

Categories

(Firefox :: Tabbed Browser, defect, P1, major)

defect

Tracking

()

VERIFIED FIXED
Firefox 3.5

People

(Reporter: sylvain.pasche, Assigned: mano)

References

Details

(Keywords: regression, verified1.9.1, Whiteboard: [fixed by bug 471499])

Attachments

(3 files, 5 obsolete files)

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.
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 :/.
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.
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
Please open a new bug for the ESC issue. The dragging-on-itself  issue is fixed.
Assignee: nobody → mano
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Thanks. I filed bug 465608 for that.
(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
By "itself" i mean on the actual tab element, that works on mac, at least for me.
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.
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 → ---
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.
The problem which was fixed is the issue raised in comment #7, which is NOT the original issue in this bug.
(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.
(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.
HMm guess you are correct.  I thought that part was at least fixed.
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"/>
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){").
Sorry, I am not familiar about the source tree.
I ask a person knowing it well.
Attached patch patch (obsolete) — Splinter Review
this sounds easier and works fine.
Attachment #349398 - Flags: review?(mano)
Attached patch patch v1.1 (obsolete) — Splinter Review
_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)
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?
Assignee: mano → mak77
mh, i found an error :\ (event -> aEvent) and that has some strange behaviour. looking at it now
Attachment #349406 - Attachment is obsolete: true
Attachment #349406 - Flags: approval1.9.1b2?
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.
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.
Attached patch patch 1.2 (obsolete) — Splinter Review
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)
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
Duplicate of this bug: 466350
Status: REOPENED → ASSIGNED
Keywords: regression
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?
(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.
(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
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.
(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
Keywords: regression
Duplicate of this bug: 466616
(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.
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.
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
(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.
Duplicate of this bug: 468537
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.
(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.
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.
Attached patch minimal patchSplinter Review
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)
check this......

adding new flavour application/x-moz-tabbrowser-tab-url to hold url from drag tab.
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
Attachment #352547 - Attachment is obsolete: true
Attachment #352609 - Flags: review?(mano)
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.
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.
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.
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.
Can we get a tryserver with this patch applied?
I tried to get a tryserver build, but for some reason the patch didn't apply, while it does in my local tree.
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
I removed the DOS the line endings from the above patch so that it applies correctly.
(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?
(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/
Attachment #352609 - Attachment is obsolete: true
Attachment #352609 - Flags: review?(mano)
Attachment #354397 - Flags: review?(mano)
Updating dependency, the patch here fixes all those bugs. Thanks Bill!
Blocks: 465332, 465910, 468553
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/
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
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
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.
Sorry for that. Adjusting assignee.
Assignee: bill → onemen.one
(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.
(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.
(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
(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.
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.
(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?
Yes, as long as that fixes the issue as described.
(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.
(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.
You can't choose 4 times, so they are actually 4 options to choose between. So 1 choice.
Can I a number one with fries?
OK sorry I made the comment that sparked all this bugspam
(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.
The link is not working
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...?)
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 35 should be addressed before attachment 352341 [details] [diff] [review] is chosen.
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.
(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.
Priority: -- → P1
Duplicate of this bug: 472685
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)
(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.
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.
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
Status: ASSIGNED → NEW
(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
Whiteboard: [patch on bug 471499]
Comment on attachment 352341 [details] [diff] [review]
minimal patch

See the other bug.
Attachment #352341 - Flags: review?(mano) → review-
Fixed by bug 471499
Status: NEW → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
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?
Whiteboard: [patch on bug 471499] → [fixed by bug 471499]
I still have this problem with the last nightly under WinXP (1.9.1b3pre).
(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.
(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
Duplicate of this bug: 478613
Target Milestone: Firefox 3.1 → Firefox 3.5
Attachment #476887 - Flags: review? → review?(mevans4900)
You need to log in before you can comment on or make changes to this bug.