102551 - Close tab does nothing if wait too much between opening the menu and clicking close

Status: VERIFIED FIXED

(SeaMonkey :: Tabbed Browser, defect)

Description

[Jerome Lacoste]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4+)
Gecko/20010930
BuildID:    2001093008

To close the tabs I use the menu that appears on right clicking on the tab and
selecting the 'close tab' option.
If you wait some time (5 sec) between the times the menu opens and you click on
the option, the tab will not be closed effectively. (I say effecttively, because
sometimes it will appear as if it had but opening a new tab will still show it)

Reproducible: Always
Steps to Reproduce:
1. Open Mozilla and go on a page (going on a page is NOT necessary, but better
than having about:blank like me)
2. Open a tab using Ctrl-T (I guess using the menus will also work)
3. Click on the new tab name with the right mouse button. A menu appears
4. Wait some seconds
5. click 'Close tab'

Actual Results:  Most of the time, the tab doesn't desappear. When it
desappears, opening a new tab will refresh the browser and the
'thought-to-be-deleted-tab' will reappear

Expected Results:  The tab desappears for real, and reopening a new tab will not
show it again.

I also had a crash when closing a tab, but I am not sure if it is related to
that behavior. Cannot reproduce it yet, so didn't report any bug. By the way,
'tabbed browser' doesn't appear in the Bugzilla helper.

Comment 1

[Jason Johnston]

Wow, that's really weird!
Confirming on Win2K build 2001100103, marking NEW.

Comment 2

[Mike Schuette]

fwiw, I can't reproduce this on win98 2001093008

Comment 3

[Justin H.]

Confim on Linux 2001101822.  Two tabs open - A and B.  Close B, the tab bar
closes, but the view shown is still tab B.  Open up a link in a new tab, you now
have tabs A, B and C.  OS == All?

Comment 4

[Jonadab the Unsightly One (Nathan Eady)]

Unable to reproduce, Win95 OSR2, Build 2001102309.
Cannot reproduce with two tabs as Justin H describes,
cannot reproduce with multiple tabs (5+).  Waited
upwards of ten seconds after opening context menu
before choosing "Close Tab" yet received the correct
("expected") results every time.  Tried with blank
tabs and also with tabs with content.  

Could some user pref be affecting this?

Comment 5

[Mike Schuette]

I am 100% unable to reproduce this on win2k 2001102603 ...

Reporter, could you download a more recent build and let us know (within 10
days) if you're still seeing this behavior?

Also, with the new tab behavior, is the new tab that's being closed focused, or
does a different tab have focus?  Do you hover over "Close Tab" or just leave
your mouse still?  Approx. how long do you have to wait?

Thanks.

Comment 6

[Mike Schuette]

Ok, in partial contradiction to what I just said, I _am_ getting the
"reappearing tab" issue, where if you wait a bit (about 10 seconds) and close
the tab, and then open a different tab, the closed tab reappears.  (So you now
have 3 tabs open.)

However, the tab will _always_ close for me.

Reporter, can you confirm or deny if this is what you're seeing?

Thanks again ...

Comment 7

[Jerome Lacoste]

I am the reporter. Sorry for not having answered lately, but I haven't upgraded
for a while, being in holydays, and then seeing the poor stability of the last
builds.

I think I will be waiting until 0.9.6 pops in and then upgrade and check this
bug again. It should be there in one week. 

Mike, if you really need for me to try this before (as in your before 10 days)
just tell me.
On 0.9.5 it is definitively there and I *hate* this bug.

Sorry for spaming.

Comment 8

[Jerome Lacoste]

I am the reporter. I think I've found why some people were unable to reproduce
the bug: the description I had made let room for two different reproductibility
steps, depending on whether one selected the menu item before or after waiting
some time.
The item selection should be made BEFORE waiting. If one opens the menu waits
and then select and click, the bug is not reproduced.
This bug can be reproduced with most of the items, except with the first one
'Open New tab' (which works) and the last one 'Close All other tabs' (when I
tried I had a bug that made me loose the current text: the remaining page was
let pointing on about:blank - I shall investigate that bug)

I've tested this with :
http://ftp.mozilla.org/pub/mozilla/nightly/latest-0.9.6/mozilla-win32-talkback.zip


This time, the OS was Windows ME, mozilla the latest I could find (2001111814)
on an identical hardware as the one used in my original bug report.

I then think that the bug description should be changed from:
'Close tab does nothing if wait too much between opening the menu and clicking
close' to:
'Most tab menu items are irresponsive if some time is let between item selection
and click'

Reproducible: Always
Steps to Reproduce:
1. Open Mozilla and go on a page (going on a page is NOT necessary, but better
than having about:blank like me)
2. Open a tab using Ctrl-T (I guess using the menus will also work)
3. Click on the new tab name with the right mouse button. A menu appears
4. Select a menu item by placing the mouse over it (e.g. Close Tab). This
problem seems to not be reproductible with the first menu item (Open New Tab).
5. Wait some seconds (threshold is around 2 seconds)
6. Click the item

Actual Results:  Most of the time, the click does nothing.

Expected Results:  the click performs the action

This is really annoying. I will vote for it.

Comment 9

[Mike Schuette]

Thanks for the additional info for reproducing this.

However, on 2001111903 I'm still seeing what I mentioned earlier ... that I can
-always- close a tab, no matter how long I wait.  If I wait <2 seconds, the tab
closes properly.  If I wait >2 seconds, the wrong tab closes.  And when I
Ctrl-T, the original tab reappears (and is still useable as normal), and I now
have 3 tabs.

Interestingly, if I Ctrl-T to make a new browser tab, press tab twice (so the
new browser tab has focus), and press the accesskey (whatever it's called next
to the winkey) to bring up the context menu, I'm unable to reproduce.

On a sidenote, this is on an ancient P166 (yes, running win2k), and I notice a
very brief hard-drive access at the 2-second mark (when I use the mouse to bring
up the context menu.)  Doubt that helps.

This is the last I'll comment on my observed behavior until something changes.

Comment 10

[Jerome Lacoste]

I reproduce that as well with 0.9.5 on my Linux box. I managed to find somebody
with 0.9.6 to reproduce it, and somebody else wasn't able to.
I saw today that bug 107276 was solved, and it bears a description a little bit
similar to that one. As I am the only one to reproduce this one consistently, I
will try to download a newest build (with 107276 fixed) and try to see if this
one was fixed as well.

Sorry for spaming.

Comment 11

[Niklas Mehner]

hmm, unfortunatly this is not fixed :(

The problem with this is the use of document.popupNode. 
I added:
dump('PopupNode: ' + document.popupNode.localName + '\n');
to the oncommand handler of the closetab menu in
http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/bindings/tabbrowser.xml#64

During "normal Operation" this dumps "tab" or "tabs", depending on whether the
menu has been created on a tab or not.

When waiting for some time, document.popupNode contains a different value. If
you leave the mouse pointer above the menu, "menupopup" is dumped, if you leave
it above the html-pane, "HTML" is dumped.

There seems to be some kind of timer involved, because this also happens
sometimes, when not waiting.

Comment 12

[Niklas Mehner]

The reason for this is imo bug 82661. When the tooltip is to be shown, for some
reason, the popupNode is set. I applied the patch in bug 82661 and this bug did
not appear anymore, unfortunatly the tooltips stopped working also.

So probably someone has to come up with a better patch for bug 82661 to fix this
one.

Comment 13

[Jerome Lacoste]

Added dependency (cf comment #12). [Hope I have the right to do so]

Comment 14

[Jerome Lacoste]

2 points:
- I copy Mike Pinkerton as he is the one that introduced the line involved in
the patch for bug 82661 (Mike, sorry if I shouldn't)
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/xul/content/src/nsXULPopupListener.cpp#953
- bug is not reproductible if you use the keyboard (keyDown or keyUp + enter) to
select the Close menu item (instead of the mouse).

Comment 15

[Jerome Lacoste]

Attachment: prevent error from being raised when bug happening

When this bug happen, an exception is thrown from tabbrowser.xml.

Error: uncaught exception: [Exception... "Index or size is negative or greater
than the allowed amount"  code: "1" nsresult: "0x80530001
(NS_ERROR_DOM_INDEX_SIZE_ERR)"	location:
"chrome://global/content/bindings/tabbrowser.xml#tabbrowser.removeTab() Line:
26"]

This is because in
http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/bindings/tabbrowser.xml#643
the tab to be closed is not located correctly. 
The patch fixes the exception while at the same time providing a log each time
the window won't close correctly.
This code should be there anyway I think as it tests a part of the tab search
postcondition (index within correct range)
PS: I used dump. I guess one could use the console instead.

Comment 16

[Niklas Mehner]

Attachment: Prevent undefined behavior

This patch prevents the tabbedbrowser from working with undefindes values. All
of the problems with closing tabs are caused by code trying to close tabs, that
are unknown. The removeTab method should either work successfull, or throw an
exception. Currently it just ignores the condition, that a tab is not found,
which leads to undefindes behavior.

Also this patch contains some minor code cleanups.

Comment 17

[Jerome Lacoste]

I am not authorized to modify my attachment.
Can someone obsolete it? Niklas refactoring supersedes it, and is much nicer as
well ;) Thanks Niklas.

Comment 18

[Niklas Mehner]

Can anybody review this patch ?
(Specially I'm not sure, if I'm throwing exceptions the right way)

Comment 19

[Niklas Mehner]

mmh, there is now some change in behavior (linux build 2001120721):
When this bug occurs I get the following exception in the JavaSctipt Console:

Error: aTab has no properties
Source File: chrome://global/content/bindings/tabbrowser.xml#tabbrowser.removeTab()
Line: 2

I think with the checkin for bug 114043, document.popupNode now contains null
instead of some other component.

Comment 20

[Steven Neil Groginsky]

I can verify this on build 20011120603 in win98se

right-click on tab, left-click on close tab on context menu

Comment 21

[Steven Neil Groginsky]

I have been using the tabs on build 20011222103 on Windows 98 SE and the problem
with other tabs being hidden on close tab seems to be fixed (OT).

I may be totally off the wall, but it currently seems that if I right click on
the tab text and left click on close tab, it works fine.  However, if I click
someplace on the tab that has no text, it does nothing.  Needs verification.

Steve

Comment 22

[Steven Neil Groginsky]

"I may be totally off the wall, but it currently seems that if I right click on
the tab text and left click on close tab, it works fine.  However, if I click
someplace on the tab that has no text, it does nothing.  Needs verification."

Build 20011222103: This apparently was not a bug.  I was imagining things.

Steve

Comment 23

[Steven Neil Groginsky]

I can consistently reproduce the bug on build 20011222103 on win 98 se.
On an open tab, I right-click to get the menu, then I wait, then I left click on
"close tab".  Sometimes the menu gets moved up so that the "close tab" is under
the pointer.  Not very often.

Do I need a definition of "spamming" ?

Steve

Comment 24

[hobbit]

I see what I believe to be this bug on Mozilla 0.9.7 on RH Linux 7.2 on a PC,
installed from blizzard's rpms.

It manifests slightly differently for me. I may have changed preferences which
caused that. (In fact, I'm sure I did: my preferences in the 'tabbed browsing'
section are: 

Comment 25

[hobbit]

argh!

I'll try that again..Linux box with 0.9.7 as above.

Okay, in case relevant: I have in tabbed browsing prefs the following
selected (on): hide tab bar when only one tab; load links in background (yay!),
and open tabs instead of windows for middle-click/controlclick. The rest
are off.

I routinely open a ton of tabs and then go through reading in order, from
the right-most to the left-most, closing them as I go.

So to reproduce, go to any list of links and open lots of tabs in the background
and then start on the rightmost, and start closing them with right-click on
tab, then mousing down to "close this tab". At some stage, I routinely find
it stops closing them. I can't close any more.

In this situation, if I right-click on the tab, and then use the arrow
keys to reach "close this tab" and return to select it: it works.

If this is a different bug, I'll re-enter it, but this looked the same thing
when I searched bugzilla. 

Apologise for the split nature of report: clearly there are keybindings
involving the tab key and forms I didn't know about! (Tried to list prefs
neatly-formatted and accidentally submitted.) Sorry!

Comment 26

[Jason Green]

Confirming on Build 2002010508 under Windows 2000 Server.  Left-clicking and
Right-clicking "Close Tab" both produce it.

Comment 27

[Tom]

I've had this same issue using 0.9.7+ (2002010903 and all earlier builds) on NT4
SP6a. Turning off "Tooltips" in the prefs seems to fix it, leading me to believe
what I've read about this bug being tooltips-related. ;)

Comment 28

[[e-mail]]

It's definitely tooltip's use of popupNode - if I cache the value of
document.popupNode when the context menu opens then I can reliably close tabs.

Unfortunately there doesn't seem to be a way of disabling tooltips on context menus.

Comment 29

[Steven Neil Groginsky]

I am finding this bug 100% reproducible for the original description in Build
2002011103 under Windows 98 SE - that is, in normal use, not *trying* to
reproduce it.  I haven't *tried* to reproduce it.  It certainly is annoying,
because the window for being able to close the tab is 1-2 seconds.  I am not
seeing any error messages.

Steve

Comment 30

[Steven Neil Groginsky]

Don't get excited before you read this whole comment.  I have an alternate way
of closing a tab from the tab context menu.  Maybe it might be of some
information or use to someone.

If you put your left-hand finger over the 'c' key and then right-click on the
tab to produce the context menu, then press 'c', it closes the tab as expected.
 You can cut the length of time of this operation way down using this method. 
Unfortunately, all this does is verify that the operation works if the code gets
the signal.  It doesn't really do anything to solve the problem.

Comment 31

[Steven Neil Groginsky]

One more time - don't get all excited about this one until you test it, and
again, this is only interesting in terms of function, not the bug itself.

It is looking like you can close a tab (I tried the last tab) by clicking on it
with the scroll button on my Intellimouse 1.2A PS/2 Compatible.  Try it and see
if it works for you!

Steve

Comment 32

[David Hyatt]

Reassigning to new component owner.

Comment 33

[[not reading bugmail]]

FWIW,

This looks like a possible flaw in the mouse hover coordinate code, or something
similar:

This mouse over problem with closing tabs is giving the similar same behavior as
trying to file bookmarks as seen in bug 124603, where mouse position will affect
the actual selection of insertion of bookmarks.

Comment 34

[[e-mail]]

Attachment: Proposed patch

This caches the document.popupNode value so that the tooltip doesn't clobber
it.

Comment 35

[jag (Peter Annema)]

Comment on attachment 69451 [details] [diff] [review]
Proposed patch

sr=jag

Comment 36

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 69451 [details] [diff] [review]
Proposed patch

r=bzbarsky

Comment 37

[[e-mail]]

Since this patch now has r=/sr= it will hopefully be applied soon. Please check
whether bug 104381 is also fixed (in particular test that it works as expected
after holding the menu open for 10-15 seconds). If not, please confirm it as NEW.

Comment 38

[[not reading bugmail]]

Steve, regarding comment 22, I've seen this with tab closing.. I was just
noticing this the other day.. it seems like it was closing only if my mouse
cursor was on the text itself, not just the highlighted area.  I had thought to
myself that was really strange.

-Dennis

Comment 39

[[e-mail]]

This has a patch, review and super-review.
It also has the patch keyword indicating that the person who wrote this patch
cannot check it into the tree.

It has been waiting like this for a week, and now the tree is closed for 0.9.9

Comment 40

[Robert O'Callahan (:roc) (email my personal email if necessary)]

a=roc+moz for 0.9.9

Comment 41

[timeless]

[e-mail]: the fix w/ r/sr was checked in before Comment #38. sorry 
drivers, your a= wasn't needed.

Comment 42

[[e-mail]]

Fix was checked in by timeless.

Comment 43

[sairuh (rarely reading bugmail)]

vrfy'd fixed using 2002.03.06 comm bits on linux rh7.2, win2k and mac 10.1.3.