User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 This is a bit obscure, but genuinely annoying over slow links. (I specifically run into this with mozilla over VNC and mozilla on X over TCP/IP) When closing the second last tab, Mozilla has two jobs to do, close and remove the tab bar, and then redraw the client area with the page content from the first (only remaining) tab. Mozilla appears to do this in a strange order, first removing the tab bar, then redrawing the web page the user just closed using the whole client area. THEN it switches to the only remaining tab content. This causes one needless screen redraw of a window the user has already tried to close, and over a slow connection, this can be several annoying seconds. Reproducible: Always Steps to Reproduce: 0. Be running mozilla over a slow link for maximum effect, such as VNC. The bug is probably too fast to notice on a modern PC at the console. 1. Ensure that "hide the tab bar when only one tab is open" is set on. 2. Open a web page on the initial screen. Any page. 3. Open a new tab. 4. In the new tab, open a second web page. For maximum effect, choose a page that is visually different than the first one, with lots of detail, like images or a background tile or something that makes it slow to redraw. 5. Close the second tab using either the widget or the keyboard shortcut. Actual Results: When you close the second window, the tab bar disappears, and the whole client area is redrawn with the "dead" window contents. Then when it's done, the window is redrawn with the correct window contents. The first redraw is wasted, because it's a redraw of a web page the user has already specifically closed. Expected Results: Mozilla should not redraw the dead window, but instead should remove the tab bar and refresh the client area with the sole remaining web page. (perhaps the close-tab-bar and redraw-client-area are done in the wrong order) Using modern theme, but likely doesn't matter.
soon a year and a half.. Reporter: Is the behaviour still the same in recent builds?
Still behaving as specified in 1.7 release. (Using a locally-built one with Xft support on Linux) Can test with later versions if needed.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.