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



UI Design
12 years ago
12 years ago


(Reporter: Steve Chapel, Assigned: neil@parkwaycc.co.uk)


(5 keywords)

Windows XP
dataloss, fixed-seamonkey1.0, fixed1.8, regression, relnote
Bug Flags:
blocking-seamonkey1.0b +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:needinfo], URL)


(2 attachments)



12 years ago
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.


12 years ago
Whiteboard: [sg:investigate]
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

12 years ago
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?
Whiteboard: [sg:investigate] → [sg:needinfo]

Comment 3

12 years ago
Hmm, this is Shockwave, not Flash.

Comment 4

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

Comment 5

12 years ago
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

12 years ago
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.
Component: Plug-ins → General
Flags: blocking-seamonkey1.0a?
Product: Core → Mozilla Application Suite
Summary: When Flash 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, clicking Back causes that tab to go back
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.
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

12 years ago
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.
Flags: blocking-seamonkey1.0a? → blocking-seamonkey1.0a-

Comment 10

12 years ago
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.
Keywords: relnote

Comment 11

12 years ago
Created attachment 196036 [details]

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

Thank you.

Comment 13

12 years ago
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

12 years ago
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.
Component: General → Tabbed Browser
Product: Mozilla Application Suite → Core
QA Contact: plugins → tabbed-browser

Comment 15

12 years ago
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.
Keywords: dataloss

Comment 16

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

Can you find a regression range?

Comment 17

12 years ago
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?
Keywords: regression
Flags: blocking1.8rc1?

Comment 18

12 years ago
not going to block for a fairly obscure bug that's seamonkey only.
Flags: blocking1.8rc1? → blocking1.8rc1-

Comment 19

12 years ago
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

12 years ago
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.
Assignee: nobody → neil.parkwaycc.co.uk
Attachment #199921 - Flags: superreview?(jag)
Attachment #199921 - Flags: review?(sebastian+bugzilla)


12 years ago
Attachment #199921 - Flags: review?(sebastian+bugzilla) → review?(iann_bugzilla)


12 years ago
Attachment #199921 - Flags: review?(iann_bugzilla) → review+

Comment 21

12 years ago
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.
Attachment #199921 - Flags: superreview?(jag) → superreview+

Comment 22

12 years ago
Fix checked in to the trunk.
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 23

12 years ago
Switching Product -> Mozilla Application Suite so I can request that it block a SeaMonkey release.
Component: Tabbed Browser → XP Apps
Flags: blocking1.8rc1-
Product: Core → Mozilla Application Suite


12 years ago
Flags: blocking-seamonkey1.0b?


12 years ago
Attachment #199921 - Flags: approval-seamonkey1.0?
Comment on attachment 199921 [details] [diff] [review]
focusedWindow null checks

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


12 years ago
Attachment #199921 - Flags: approval-seamonkey1.0? → approval-seamonkey1.0+

Comment 25

12 years ago
SeaMonkey-only fix checked in to the 1.8 branch.
Keywords: fixed1.8
Whiteboard: [sg:needinfo] → [sg:needinfo] fixed-seamonkey1.0
Flags: blocking-seamonkey1.0b? → blocking-seamonkey1.0b+
Keywords: fixed-seamonkey1.0
Whiteboard: [sg:needinfo] fixed-seamonkey1.0 → [sg:needinfo]
You need to log in before you can comment on or make changes to this bug.