Closed Bug 372290 Opened 17 years ago Closed 14 years ago

close of a tab with many tabs under heavy system load removes the upper tab well b4 the pane...

Categories

(Firefox :: Tabbed Browser, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: roy.crabtree, Unassigned)

Details

(Whiteboard: [CLOSEME 2010-11-15])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2

where the user can become confused if there are (possibly or actually) two similar tabbed panes in contents OR label on the screen:  the user will then hit the NEXT tab "X" to remove the NEXT window pane FOR that next tab, and will do so on the basis of the PREVIOUS window pane contents:

-- if the system or browser locks (multiple clicks)
-- or is massively slow (this bug)

The display should ALWAYS be set up to LOCK itself in a consistent state until all display elements are up to date BEFORE changing any contents on the display.  If MS Windows (or X Windows, etc.) have bugs that cause this to crop up, then Firefox needs to possibly allow an Option to protect itself from this pronblem (which MUST be ON by DEFAULT), where Firefox calculates, flushes, and forces these items in as safe and sane a form as possible.

Reproducible: Sometimes

Steps to Reproduce:
1. Load the system (WMP ripping, a  file download or two, and many tabs)
2. Use the mouse (not confirmed for the other ways) to clock on the tabs close "X"
3.Watch the tab top vanish, and the window pane stay the same.

If two windows/tabs have similar contents OR tab labels, this may fool the user into tab X-ing twice, and then two tabs vanish.
Actual Results:  
Two X-es kills two distinct window/tabs where they are NOT dups or similar contents.  The window pane display of the tab does NOT show the SECOND window UNTIL AFTER the clock of the SECOND "X", and this wipes the second window with no way to reliably get back to a streaming or non-recoverable situation.

Expected Results:  
When you kill a tab, the tab top should NOT vanish UNLESS the update ALSO includes ALL visual elements;

SIMILARLY FOR ANY OTHER BROWSER ACTION:  the actual display MUST NOT EVER BE INCONSISTENT IN ANY FASHION relative tot he actions being taken.

Stay consistent visually at all times; provide a roll back archive journal to back out or repay ANY sequence undertaken.  The security issue is that any malicious site can cause this type of bug by causing such a load within the browser itself.
Mistakenly closed tabs can be re-opened with Ctrl-shift-T or through the History menu. This is more of a potential annoyance than an exploit that needs to be hidden.
Group: security
URL: n/a
This bug was reported using Firefox 3.0 or older, which is no longer supported. The bug has also not been changed in over 500 days and is still in UNCO.
Reporter, please retest this bug in Firefox 3.6.10 or later using a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles. If you still see this problem, please update the bug. If you no longer see the bug, please set the resolution to RESOLVED, WORKSFORME.

This is a mass search of unconfirmed bugs that have no activity on them, so if you feel a bug was marked in error, just remove the CLOSEME comment in the whiteboard within the next month.
Whiteboard: [CLOSEME 2010-11-15]
No reply, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.