Closed
Bug 304243
Opened 19 years ago
Closed 19 years ago
When Flash Shockwave or Java Applet plug-in is active on another tab, clicking Back causes that tab to go back
Categories
(SeaMonkey :: UI Design, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: schapel, Assigned: neil)
References
()
Details
(5 keywords, Whiteboard: [sg:needinfo])
Attachments
(2 files)
674 bytes,
text/html
|
Details | |
2.23 KB,
patch
|
iannbugzilla
:
review+
jag+mozilla
:
superreview+
iannbugzilla
:
approval-seamonkey1.0+
|
Details | Diff | Splinter Review |
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.
Updated•19 years ago
|
Whiteboard: [sg:investigate]
Comment 1•19 years ago
|
||
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•19 years ago
|
||
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?
Whiteboard: [sg:investigate] → [sg:needinfo]
Comment 3•19 years ago
|
||
Hmm, this is Shockwave, not Flash.
Comment 4•19 years ago
|
||
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
Reporter | ||
Comment 5•19 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.
Reporter | ||
Comment 6•19 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.
Comment 8•19 years ago
|
||
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•19 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-
Reporter | ||
Comment 10•19 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
Reporter | ||
Comment 11•19 years ago
|
||
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.
Reporter | ||
Comment 13•19 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•19 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
Reporter | ||
Comment 15•19 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•19 years ago
|
||
OK, then I'm not seeing this on linux. Can you find a regression range?
Reporter | ||
Comment 17•19 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•19 years ago
|
||
not going to block for a fairly obscure bug that's seamonkey only.
Flags: blocking1.8rc1? → blocking1.8rc1-
Comment 19•19 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?
Assignee | ||
Comment 20•19 years ago
|
||
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
Status: NEW → ASSIGNED
Attachment #199921 -
Flags: superreview?(jag)
Attachment #199921 -
Flags: review?(sebastian+bugzilla)
Assignee | ||
Updated•19 years ago
|
Attachment #199921 -
Flags: review?(sebastian+bugzilla) → review?(iann_bugzilla)
Attachment #199921 -
Flags: review?(iann_bugzilla) → review+
Comment 21•19 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+
Assignee | ||
Comment 22•19 years ago
|
||
Fix checked in to the trunk.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 23•19 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
Reporter | ||
Updated•19 years ago
|
Flags: blocking-seamonkey1.0b?
Assignee | ||
Updated•19 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?)
Attachment #199921 -
Flags: approval-seamonkey1.0? → approval-seamonkey1.0+
Assignee | ||
Comment 25•19 years ago
|
||
SeaMonkey-only fix checked in to the 1.8 branch.
Keywords: fixed1.8
Whiteboard: [sg:needinfo] → [sg:needinfo] fixed-seamonkey1.0
Updated•19 years ago
|
Flags: blocking-seamonkey1.0b? → blocking-seamonkey1.0b+
Updated•18 years ago
|
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.
Description
•