377755 - Closing a tab is ignored or causes a different tab to close

Status: VERIFIED DUPLICATE of bug 323805

(Firefox :: Tabbed Browser, defect)

Description

[Duncan Loveday]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070415 Minefield/3.0a4pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070415 Minefield/3.0a4pre

Closing a tab, either programmatically using window.close() or by clicking the little cross on it in the UI, sometimes causes a different tab to close.

Reproducible: Sometimes

Steps to Reproduce:
Unfortunately I cannot recreate this in a simple test case as yet - will keep trying. I can reliably reproduce it in my running app but it is a monster, not really feasible to provide the whole thing as a test case.
Actual Results:  
Clicking the little cross on one tab sometimes closes another, and sometimes nothing happens. Sometimes, clicking to select another tab is also ignored.


My app has an initial tab which stays open and from which a series of popup windows or tabs (depending on the users' preference) are opened. Unload handlers are used to create something similar to "modal" windows. My app works perfectly using either tabs or popups in FF2 and using popups in FF3. The problems only appear when using tabs in FF3. It is as if the browser can lose track of which tab corresponds to which target name. When the initial tab tries to close the first child tab, it sometimes closes itself. Sometimes switching between tabs from the UI is ignored. Closing tabs from the UI is sometimes ignored and sometimes closes the wrong tab.

Comment 1

[Duncan Loveday]

Marking as a regression since the problems described do not occur in FF2.

Comment 2

[Duncan Loveday]

Just noticed, whenever the wrong tab is closed from the UI I get this in the error console

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMXULElement.boxObject]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://global/content/bindings/browser.xml :: get_docShell :: line 0"  data: no]

Error: uncaught exception: [Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIDOMJSWindow.setTimeout]"  nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame :: http://localhost:7001/BPTMPresentation/Thread.js :: sleep :: line 212"  data: no]

Comment 3

[Duncan Loveday]

Attachment: test HTML source 1 of 3

Finally got at least part of this recreated in a reasonable test case.

Comment 4

[Duncan Loveday]

Attachment: test HTML source 2 of 3

Comment 5

[Duncan Loveday]

Attachment: test HTML source 3 of 3

Comment 6

[Duncan Loveday]

Attachment: test SVG source 1 of 1

Comment 7

[Duncan Loveday]

The thing I was missing is that SVG is essential to this bug. Perhaps this ought to be reassigned to the SVG component ?

To recreate

1) Place the four attachments in a directory
2) Open test1.html in Firefox 3 trunk build.
3) Click the "open tab" button
4) A second tab opens containing an embedded SVG with a hyperlink "Click me".
5) Click on the hyperlink. A third tab opens.
6) Now return to the first tab and click the "close tab" button.

Actual result: The wrong tab is closed. The javascript code in tab 1 should close tab 2 but it actually closes tab 1, itself. You end up with just 2 and 3 open although the tab titles suggest 1 and 3.

Try the same thing in FF 2 and it is fine.

I think this is quite a serious regression so upping the severity a bit (hope this doesn't break etiquette.

Comment 8

[Duncan Loveday]

Attachment: test HTML source 2 of 3, version that works live in the bug

Comment 9

[Duncan Loveday]

Attachment: test HTML source 1 of 3, version that works live in the bug

Comment 10

[Duncan Loveday]

See also bug 377948, raised against SVG in Core component

Comment 11

[Duncan Loveday]

It might be worth noting that after executing the 6 steps above, attempting to close tab 1 is ignored. Also, my history in the initial tab gets wiped from the moment I click on the SVG hyperlink in step 5. Finally, after completing the six steps if I navigate to any page with a form - google, bugzilla or whatever - I can't type text in any of the fields. It does seem to be well and truly broken.

Comment 12

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070418 Minefield/3.0a4pre

I can confirm that the Close Tab button on the page doesn't close the current active tab but one of the other inactive tabs and that after closing that inactive tab the tab's close button (or middle click function) doesn't work anymore.

I get also some errors:

(3x) Error: this.mCurrentBrowser.focusedElement.blur is not a function
Source File: chrome://global/content/bindings/tabbrowser.xml
Line: 693

Error: this.docShell has no properties
Source File: chrome://global/content/bindings/browser.xml
Line: 0

(2x) Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMXULElement.boxObject]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://global/content/bindings/browser.xml :: get_docShell :: line 0"  data: no]
Source File: chrome://global/content/bindings/browser.xml
Line: 0

I can't find a regression range for this. The problem existed already in the last months of 2005 and before that the testcase didn't work (click me link missing).

Comment 13

[Duncan Loveday]

Ria, I think the reason why "Click me" is missing in FF2 and probably other branch builds because I've forgotton to put type="image/svg+xml" in the <embed>. Not sure why it would work in some cases and not others. Will get on to this, unfortunately it will mean checking in and obsoleting several attachments.

Comment 14

[Duncan Loveday]

Attachment: test html source 2 of 3

Comment 15

[Duncan Loveday]

Attachment: test html source 1 of 3

Comment 16

[Duncan Loveday]

Ria, this is now working in FF2.

Comment 17

[Duncan Loveday]

(In reply to comment #12)

Ria, just to make sure I've explained the problem properly, the correct behaviour as seen in FF2 is

Before clicking "close tab" (step 6)

Tab 1 -> PAGE 1
Tab 2 -> PAGE 2
Tab 3 -> PAGE 3

After clicking "close tab" (step 6)

Tab 1 -> PAGE 1
Tab 2 -> PAGE 3

In the trunk builds what I see is

After clicking "close tab" (step 6)

Tab 1 -> PAGE 2
Tab 2 -> PAGE 3

In other words, clicking "close tab" in tab 1 is meant to close the page in tab 2 but in the trunk it incorrectly closes the page in tab 1. So the result is pages 2 and 3 left open although the headings of tabs 1 and 2 indicate pages 1 and 3. The tab headings are actually correct but the contents of tab 1 is wrong and does not match the heading.

Comment 18

[Ria Klaassen (not reading all bugmail)]

In trunk when I click "close tab" it closes the tab with https://bugzilla.mozilla.org/attachment.cgi?id=262141 in it (the second one).
So here the behaviour is equal in trunk and branch.
After this when I attempt to close the first tab it does not succeed (in trunk) but throws errors instead. And this is a regression between 2005-06-06 06 and 2005-06-07 06. The range has two tabs related bugs in it: bug 295721 and bug 179656. Branch shows no errors.

Sorry if I misunderstand the problem and discover new ones instead.. :)

Other strange behaviour was already present before: the address in the location bar did not match the focused tab anymore after clicking the "click me" link.

Comment 19

[Duncan Loveday]

This is all very confusing and it sounds as if you might be getting a different effect from me.

(In reply to comment #18)
> In trunk when I click "close tab" it closes the tab with
> https://bugzilla.mozilla.org/attachment.cgi?id=262141 in it (the second one).
> So here the behaviour is equal in trunk and branch.

But are the *contents* of your tabs correct - i.e. of the two tabs that remain open the first should contain "PAGE 1" and then second "PAGE 3". The bug I'm seeing is that with the trunk the first tab contains "PAGE 2" instead of "PAGE 1".

> After this when I attempt to close the first tab it does not succeed (in trunk)
> but throws errors instead. And this is a regression between 2005-06-06 06 and
> 2005-06-07 06. The range has two tabs related bugs in it: bug 295721 and bug
> 179656. Branch shows no errors.


> Sorry if I misunderstand the problem and discover new ones instead.. :)
> Other strange behaviour was already present before: the address in the location
> bar did not match the focused tab anymore after clicking the "click me" link.

I haven't been checking the contents of the address in the location bar against the focussed tab, although I'm happy to take your word for it that a mismatch exists and has always existed. What I'm pointing out is a mismatch between tab *contents* and tab headings. The tab contents are wrong and the headings are right. This is definitely not the case in FF 2 where everything works OK.

I'll attach a couple of image files for absolute clarity.

Comment 20

[Duncan Loveday]

Attachment: Firefox 2 - correct result, showing PAGE 1

Comment 21

[Duncan Loveday]

Attachment: Firefox 3 - incorrect result, showing PAGE 2

Comment 22

[Duncan Loveday]

FWIW, in FF2 I never observe a mismatch between the address in the location bar and the focussed tab. But in the trunk, when I execute step 5 (clicking on the SVG "Click me" hyperlink) the address in the location bar does not update and in fact it does not change from then on regardless of what tabs I select or close.

Comment 23

[Ria Klaassen (not reading all bugmail)]

Ah yes, you're right, the first tab contains the contents of the second tab. In trunk it looks like this stems from the beginning of SVG.
I don't know why branch does it right. Something fixed it on branch in March 2006 but I can't find trunk builds without this bug.

Comment 24

[Ria Klaassen (not reading all bugmail)]

Since these are, I think, basically SVG problems, CC-ing [e-mail] and [e-mail]

Comment 25

[Jonathan Watt [:jwatt]]

(In reply to comment #12)
> (3x) Error: this.mCurrentBrowser.focusedElement.blur is not a function
> Source File: chrome://global/content/bindings/tabbrowser.xml
> Line: 693

This is probably the root of the problem. The browser code has really got to stop calling .focus() and .blur() on arbitrary elements. These functions only exist on HTML elements.

Comment 26

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #25)
> This is probably the root of the problem. The browser code has really got to
> stop calling .focus() and .blur() on arbitrary elements. These functions only
> exist on HTML elements.

That would make this a dupe of bug 323805, I believe.

Comment 28

[Duncan Loveday]

Just to confirm: This bug now appears to have gone away.

Comment 29

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified dup