Last Comment Bug 304243 - When Flash Shockwave or Java Applet plug-in is active on another tab, clicking Back causes that tab to go back
: When Flash Shockwave or Java Applet plug-in is active on another tab, clickin...
: dataloss, fixed-seamonkey1.0, fixed1.8, regression, relnote
Product: SeaMonkey
Classification: Client Software
Component: UI Design (show other bugs)
: Trunk
: x86 Windows XP
-- normal (vote)
: ---
Assigned To:
Depends on:
  Show dependency treegraph
Reported: 2005-08-10 19:25 PDT by Steve Chapel
Modified: 2006-03-25 04:10 PST (History)
6 users (show)
cbiesinger: blocking‑seamonkey1.0b+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

relnote (674 bytes, text/html)
2005-09-14 06:51 PDT, Steve Chapel
no flags Details
focusedWindow null checks (2.23 KB, patch)
2005-10-18 04:11 PDT,
iann_bugzilla: review+
jag-mozilla: superreview+
iann_bugzilla: approval‑seamonkey1.0+
Details | Diff | Splinter Review

Description User image Steve Chapel 2005-08-10 19:25:56 PDT
Reproducible: Always

Steps to Reproduce:
1. Go to
2. Click the Start flash button
3. Click the GO flash button
4. Open another tab, and navigate to another page so the Back button becomes active
5. Click the Back button while the new tab is the active tab

Expected Results: The active tab goes back to the previous page.
Actual Results: The tab with the Flash plug-in goes back to its previous page.

I can reproduce this in SeaMonkey trunk build 2005081005, and have been seeing
this bug in nightly trunk builds for the past several weeks. I'm using Windows
XP SP2. It doesn't seem to happen with all Flash plug-ins, only certain ones in
certain situations.
Comment 1 User image Ria Klaassen (not reading all bugmail) 2005-08-11 07:16:48 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050811
Firefox/1.0+ ID:2005081104

Works for me both with Flash 7.0 r19 and Flash 8.0 r5.
Comment 2 User image Jesse Ruderman 2005-08-16 20:21:24 PDT
Flash 7,0,24,0
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050816

Steve -

What version of Flash are you using?

Do you see this bug in current trunk nightly builds of Firefox?

Can you give more specific steps to reproduce -- in particular, how do you open
the new tab and navigate in it?
Comment 3 User image Jesse Ruderman 2005-08-16 22:53:59 PDT
Hmm, this is Shockwave, not Flash.
Comment 4 User image Jesse Ruderman 2005-08-16 22:59:26 PDT
* Windows XP SP2
* Shockwave (latest?)
* Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716
Comment 5 User image Steve Chapel 2005-08-17 06:01:02 PDT
I've got Macromedia Shockwave for Director Netscape plug-in, version 10.1 installed.

I can reproduce the bug in the 2005081205 trunk build SeaMonkey with a new
profile, but I cannot reproduce it in the 20050812 trunk build of Firefox.
Perhaps it's SeaMonkey only?

When I tried to reproduce the problem, I found that sometimes I couldn't, but if
I went back to the Shockwave app and clicked Stop and then Go, I could
reproduce. Of course, I could still reproduce only with SeaMonkey.

I reproduced the problem by opening the new tab using the New Tab icon in the
tab bar and by selecting File | New | Navigator Tab. I also reproduced the
problem by navigating to the new page by clicking a link, typing a URL into the
address bar, and by selecting a Bookmark.

I tried reproducing in Firefox by selecting File | New Tab and by typing Ctrl+T,
and by navigating all the ways I mentioned for SeaMonkey, but still I could
reproduce the problem only in SeaMonkey.
Comment 6 User image Steve Chapel 2005-09-07 13:06:25 PDT
Updating Summary and Product to reflect that this also occurs with Java applets
and is apparently a SeaMonkey-only bug. I think this is also serious enough to
block SeaMonkey 1.0.
Comment 7 User image Chris Thomas (CTho) [formerly] 2005-09-07 14:24:47 PDT
I can reproduce this with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b4) Gecko/20050730 SeaMonkey/1.0a.  I *think* I have jst's splitwindow
patch in my tree.
Comment 8 User image Jürgen 'JiHa' Harter 2005-09-07 14:43:58 PDT
I can reproduce this wwith Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9a1) Gecko/20050828 SeaMonkey/1.1a and Shockwave Flash 7.0 r19

But only if the flash is really "used" by "drawing" something with it.
Comment 9 User image Robert Kaiser 2005-09-07 15:02:23 PDT
From info here, it looks like it's rarely seen and only happening for
edge-cases, so not actually blocking Alpha-testing. Additionally, Alpha is more
or less out the door, with 1.8b4 being immanent (though we still have a need to
get builds somehow), so we need to be _very_ conservative about marking new
blockers or we won't get anywhere.

So, we won't hold Alpha for this, but more info about what's going on is
certainly wanted, and once we know more and it's really severe enough, you
probably can consider nominating for Beta again later.
Comment 10 User image Steve Chapel 2005-09-08 19:49:41 PDT
How about a relnote? Quite a few people might run into this problem, but not be
able to characterize the behavior they see. The relnote could characterize the
behavior for them, and point them to this bug report. Then we could see how many
people are experiencing the problem and how severe they think it is. I'm willing
to volunteer to write the relnote, in fact.
Comment 11 User image Steve Chapel 2005-09-14 06:51:19 PDT
Created attachment 196036 [details]

My first try at a release note.
Comment 12 User image Chris Thomas (CTho) [formerly] 2005-09-14 15:49:58 PDT
(In reply to comment #11)
> Created an attachment (id=196036) [edit]
> relnote
> My first try at a release note.

Thank you.
Comment 13 User image Steve Chapel 2005-09-20 08:10:29 PDT
This seems to be related to keyboard focus. When a Java applet gets keyboard
focus, and then I switch to another tab, in SeaMonkey 1.0a the applet still has
keyboard focus, but in Firefox 1.5 beta 1 the applet doesn't still have keyboard
focus. Apparently, the keyboard focus makes the tab with the plugin get the
navigation event instead of the current tab.
Comment 14 User image Andrew Schultz 2005-09-25 20:56:16 PDT
Attempting to find a better component.

Is there a page with a java applet where I can reproduce this?  There's no
shockwave for linux.
Comment 15 User image Steve Chapel 2005-09-25 21:14:35 PDT
Just about any Java applet will do. I just randomly picked and gave the applet keyboard
focus by typing in one of the text fields (I'm using Java(TM) 2 Platform
Standard Edition 5.0 Update 5). I also discovered tonight that the problem
happens with the Adobe Acrobat 7.0 plugin too.

This bug can cause all the data entered into a Java applet to be lost, so I'm
marking this as a dataloss bug.
Comment 16 User image Andrew Schultz 2005-09-25 22:05:28 PDT
OK, then I'm not seeing this on linux.

Can you find a regression range?
Comment 17 User image Steve Chapel 2005-09-26 08:29:58 PDT
The problem occurs in Mozilla trunk build 2005030906, but doesn't occur in trunk
build 2005030806. Could it be bug 284993 that caused this regression?
Comment 18 User image Asa Dotzler [:asa] 2005-10-17 11:18:10 PDT
not going to block for a fairly obscure bug that's seamonkey only.
Comment 19 User image Boris Zbarsky [:bz] (still a bit busy) 2005-10-17 21:41:40 PDT
So the real question is why the focus stuff doesn't work right in the seamonkey
version of tabbrowser, right?  It should be storing the focused node, etc, per
tab, but then blurring it until that tab is switched to...  The one difference I
see in updateCurrentBrowser() (which got changed in the relevant time frame) is
that toolkit has a |if (focusedWindow && == window.content) {|
check while xpfe has a |if ( == window.content) {| check.

I'm guessing the fix for bug 287467 never made it to xpfe and needs to do so?
Comment 20 User image 2005-10-18 04:11:48 PDT
Created attachment 199921 [details] [diff] [review]
focusedWindow null checks

Note: the tasksOverlay check is different because of a bug claiming that
sometimes the intermediate variables are null too.
Comment 21 User image jag (Peter Annema) 2005-12-02 03:30:28 PST
Comment on attachment 199921 [details] [diff] [review]
focusedWindow null checks

I'd prefer to explicitely null check, though that'll be a lot of null checks if we can't count on document and commandDispatcher not to be null. (Why? Add comment perhaps?)

I guess sr=jag then.
Comment 22 User image 2005-12-02 06:33:26 PST
Fix checked in to the trunk.
Comment 23 User image Steve Chapel 2005-12-10 13:09:53 PST
Switching Product -> Mozilla Application Suite so I can request that it block a SeaMonkey release.
Comment 24 User image Chris Thomas (CTho) [formerly] 2005-12-11 09:52:17 PST
Comment on attachment 199921 [details] [diff] [review]
focusedWindow null checks

first a=me, need one more (Neil?)
Comment 25 User image 2005-12-11 14:11:30 PST
SeaMonkey-only fix checked in to the 1.8 branch.

Note You need to log in before you can comment on or make changes to this bug.