Closed
Bug 406744
Opened 17 years ago
Closed 14 years ago
Invoking document.getElementById while an applet is loading causes the applet to be stopped, destroyed and re-inited
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: paul.p.carey, Unassigned)
Details
(Keywords: regression, testcase, Whiteboard: [closeme 2010-05-05])
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1
If a script block retrieves a reference to an applet via document.getElementById immediately after the applet has been loaded, the newly loaded applet is stopped and destroyed and a new applet is created.
Note that this behaviour occurs not only when the applet is loaded as part of a normal page load, as per the attached test case. It also occurs when the applet is loaded on demand, for example, by setting the innerHTML of a container to the applet tag in response to a user action.
Reproducible: Always
Steps to Reproduce:
1. Extract the attached jar by running jar xvf appletreload.jar
2. Modify the archive attribute of line 17 of diagnostic.html appropriately
3. Open diagnostic.html in Firefox (bug reproduced in 3.0b1 and 2.0.0.11, not in 2.0.0.7)
4. To view the correct behaviour - that the applet is not destroyed - simply comment out line 21.
Actual Results:
An applet is created and detroyed, then a new applet is created.
Expected Results:
Only a single applet should be created.
Invoking retrieveAppletRef manually (by clicking retrieveAppletRef) invokes the same function as that which causes the bug, but it doesn't cause the applet to be destroyed and reloaded. That suggests to me that a race condition is highlighted by invoking document.getElementById, that perhaps sends a spurious APPLET_DESTROY method.
I reproduced this bug in 3.0b1 and 2.0.0.11 but not 2.0.0.7.
Reporter | ||
Comment 1•17 years ago
|
||
Reporter | ||
Comment 2•17 years ago
|
||
Reporter | ||
Comment 3•17 years ago
|
||
End of description meant to state APPLET_DESTROY event, not method.
Updated•17 years ago
|
Attachment #291411 -
Attachment mime type: application/octet-stream → text/plain
Updated•17 years ago
|
Attachment #291410 -
Attachment mime type: application/octet-stream → application/java-archive
Comment 4•17 years ago
|
||
Is this a consequence of bug 90268, somehow?
Component: General → Plug-ins
Keywords: regression,
testcase
Product: Firefox → Core
QA Contact: general → plugins
Version: unspecified → Trunk
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a4) Gecko/20100407 MozillaDeveloperPreview/3.7a4
Please update if you are able to still reproduce with the latest nightly build ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/
Whiteboard: [closeme 2010-05-05]
Comment 6•14 years ago
|
||
Closing since now after whiteboard closeme date and no reply to last comment.
Please reopen/comment with further info, if you still see this issue with Firefox 3.6.13 or later, with a clean profile and the latest version of the plugin.
If you wish, you can also try to reproduce in Firefox 4 Beta 8 or later:
http://www.mozilla.com/en-US/firefox/all-beta.html
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Hardware: PowerPC → x86
Resolution: --- → INCOMPLETE
Version: Trunk → 1.9.0 Branch
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•