304243 - When Flash Shockwave or Java Applet plug-in is active on another tab, clicking Back causes that tab to go back

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Steve Chapel]

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.noggin.com/games/scribblevision/index.php?modid=13
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

[Ria Klaassen (not reading all bugmail)]

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

[Jesse Ruderman]

WFM
Flash 7,0,24,0
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050816
Firefox/1.0+

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

[Jesse Ruderman]

Hmm, this is Shockwave, not Flash.

Comment 4

[Jesse Ruderman]

WFM
* Windows XP SP2
* Shockwave (latest?)
* Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716
Firefox/1.0.6

Comment 5

[Steve Chapel]

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

[Steve Chapel]

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

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

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

[Jürgen 'JiHa' Harter]

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

[Robert Kaiser]

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

[Steve Chapel]

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

[Steve Chapel]

Attachment: relnote

My first try at a release note.

Comment 12

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #11)
> Created an attachment (id=196036) [edit]
> relnote
> 
> My first try at a release note.

Thank you.

Comment 13

[Steve Chapel]

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

[Andrew Schultz]

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

[Steve Chapel]

Just about any Java applet will do. I just randomly picked
http://www.lightandmatter.com/area2planet.shtml 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

[Andrew Schultz]

OK, then I'm not seeing this on linux.

Can you find a regression range?

Comment 17

[Steve Chapel]

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

[Asa Dotzler [:asa]]

not going to block for a fairly obscure bug that's seamonkey only.

Comment 19

[Boris Zbarsky [:bzbarsky]]

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 && focusedWindow.top == window.content) {|
check while xpfe has a |if (focusedWindow.top == window.content) {| check.

I'm guessing the fix for bug 287467 never made it to xpfe and needs to do so?

Comment 20

[[e-mail]]

Attachment: focusedWindow null checks

Note: the tasksOverlay check is different because of a bug claiming that
sometimes the intermediate variables are null too.

Comment 21

[jag (Peter Annema)]

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

[[e-mail]]

Fix checked in to the trunk.

Comment 23

[Steve Chapel]

Switching Product -> Mozilla Application Suite so I can request that it block a SeaMonkey release.

Comment 24

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Comment on attachment 199921 [details] [diff] [review]
focusedWindow null checks

first a=me, need one more (Neil?)

Comment 25

[[e-mail]]

SeaMonkey-only fix checked in to the 1.8 branch.