Closed
Bug 33111
Opened 25 years ago
Closed 23 years ago
Allow applets to be created dynamically
Categories
(Core :: DOM: Core & HTML, defect, P4)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: desale, Assigned: nisheeth_mozilla)
References
Details
(Keywords: dom1, testcase)
Attachments
(5 files)
Application on creating applet node.
BUILDS: 2000-03-23-06.
STEPS TO REPRODUCE:
1] Load the attachment I'm providing with above specified builds.
2] Click "Create Applet" button.
OR
1] Copy testcase I'm providing. Open this testcase with above specified builds.
2] Click "Create Applet" button.
EXPECTED RESULT:
New APPLET node should get created and then get appended to BODY.
ACTUAL RESULTS:
Application crashes.
TESTCASE CODE START:
<html>
<head>
<title>Applet Testing</title>
</head>
<script>
<!--
function createapplet(sHTMLelement, sAttribute1, sAttributeval1, sAttribute2,
sAttributeval2)
{
var sHTMLelm, sAttr1, sAttr2, sAttrVal1, sAttrVal2;
sHTMLelm = sHTMLelement.toLowerCase();
sAttr1 = sAttribute1.toLowerCase();
sAttr2 = sAttribute2.toLowerCase();
sAttrVal1 = sAttributeval1.toLowerCase();
sAttrVal2 = sAttributeval2.toLowerCase();
var oBody = document.getElementsByTagName("BODY").item(0);
var oNode = document.createElement(sHTMLelm);
oBody.appendChild( oNode );
}
//-->
</script>
<body>
<form>
<input type="button" name="create applet" Value="Create Applet"
onClick="createapplet('APPLET', 'code', 'applet1.class', 'codebase',
'http://bubblegum/desale/applets/');">
</form>
</body>
</html>
TESTCASE CODE END:
|
Reporter | |
Comment 1•25 years ago
|
||
|
|
Reporter | |
Comment 2•25 years ago
|
||
STACK TRACE:
Call Stack: (Signature = nsHTMLAppletElement::GetScriptObject 28d95eae)
nsHTMLAppletElement::GetScriptObject
[d:\builds\seamonkey\mozilla\layout\html\content\src\nsHTMLAppletElement.cpp,
line 299]
nsJSUtils::nsConvertObjectToJSVal
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSUtils.cpp, line 266]
DocumentCreateElement
[d:\builds\seamonkey\mozilla\dom\src\coreDOM\nsJSDocument.cpp, line 384]
js_Invoke
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 666]
js_Interpret
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2293]
js_Invoke
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 682]
js_Interpret
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2293]
js_Invoke
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 682]
js_InternalInvoke
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 755]
JS_CallFunctionValue
[d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 2792]
nsJSContext::CallEventHandler
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 566]
nsJSEventListener::HandleEvent
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 129]
nsEventListenerManager::HandleEventSubType
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventListenerManager.cpp, line
701]
nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventListenerManager.cpp, line
845]
nsGenericElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\layout\base\src\nsGenericElement.cpp, line 1010]
nsHTMLInputElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\layout\html\content\src\nsHTMLInputElement.cpp,
line 836]
nsEventStateManager::CheckForAndDispatchClick
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventStateManager.cpp, line
1712]
nsEventStateManager::PostHandleEvent
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventStateManager.cpp, line
893]
PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 3035]
nsView::HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 799]
nsView::HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 784]
nsView::HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 784]
nsViewManager2::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1216]
HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 69]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 497]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 514]
nsWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2995]
ChildWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3211]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2289]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 672]
KERNEL32.DLL + 0x35d9 (0xbff735d9)
KERNEL32.DLL + 0x2222f (0xbff9222f)
0x00688bdc
|
||
Updated•25 years ago
|
Severity: normal → critical
Updating [beta2+] in Status Summary to [nsbeta2+]
Keywords: beta2
Whiteboard: [beta2+] → [nsbeta2+]
|
||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → M16
|
|
||
Comment 5•25 years ago
|
||
The applet element when created in JS does not know its document but it assumes
the document is known and blindly accesses the document pointer which happens
to be null. I have a fix for the crasher, but the applet loading when the
element is created dynamically does not work, nor will I be able to get that
fixed today. I'll fix the crash.
Whiteboard: [nsbeta2+] → [nsbeta2+] (CRASH WILL BE FIXED)
|
|
||
Comment 6•25 years ago
|
||
The crash is fixed, removing nsbeta2 keywords since I'll leave this open to fix
crating applets dynamically.
|
|
||
Comment 8•25 years ago
|
||
Changing status whiteboard and removing crash keyword
Keywords: crash
Whiteboard: [nsbeta2+] (CRASH WILL BE FIXED) → [nsbeta2+] (CRASH IS BE FIXED)
|
|
||
Updated•25 years ago
|
Whiteboard: [nsbeta2+] (CRASH IS BE FIXED) → [nsbeta2+] (CRASH IS FIXED)
|
Assignee | |
Comment 10•24 years ago
|
||
Taking from jst as discussed in the XML/DOM bug distribution meeting...
Assignee: jst → nisheeth
Status: ASSIGNED → NEW
|
|
Assignee | |
Comment 11•24 years ago
|
||
Updating summary, re-targeting for M18 and marking nsbeta3...
|
|
Assignee | |
Comment 12•24 years ago
|
||
Triaging beta 3 nominees and marking this future. We should be able to live
without the ability to create applets dynamically for FCS.
Target Milestone: M18 → Future
|
|
Assignee | |
Comment 13•24 years ago
|
||
I forgot to thank Eric Krock in my last comment for pointing this bug out as a
futurable bug.
This bug has been marked "future" because the original netscape engineer working
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way
-- please attach your concern to the bug for reconsideration.
Keywords: nsbeta3
|
||
Comment 14•24 years ago
|
||
*** Bug 49483 has been marked as a duplicate of this bug. ***
|
||
Updated•24 years ago
|
Component: DOM Level 1 → DOM HTML
|
|
Reporter | |
Comment 15•23 years ago
|
||
Updating QA contact to Shivakiran Tummala.
QA Contact: desale → stummala
|
||
Comment 16•23 years ago
|
||
Worksforme. (Build ID: 2002 01 24 03/Win98).
Could we close that one now ?
/jc
|
||
Comment 17•23 years ago
|
||
this bug is applicable if the applets cannot be created dynamically.
|
||
Comment 18•23 years ago
|
||
Severity -> normal, no longer crashes. Priority P4, there's no real world site
that shows this, and it's not a common technique. Workaround is obvious.
All/All.
Severity: critical → normal
Keywords: testcase
OS: Windows 95 → All
Priority: P3 → P4
Hardware: PC → All
|
|
Reporter | |
Comment 19•23 years ago
|
||
Agree since no real world site use.
|
||
Comment 20•23 years ago
|
||
hmm, we completely disagree... maybe real world site are not gonna use it. but
real world application do have a strong need for this!
since we want to create our gui completely in javascript (no html tags) and
dynamically add and remove applets to the dom, it would be a big disadvantages
not having the applet element and its properties accessible from javascript.
Olaf
Tom
|
|
||
Comment 21•23 years ago
|
||
Actually this works for me now that I test it... even in Mozilla 0.9.7 it works.
Olaf could you try it please? And attach a testcase that doesn't work please?
Also make sure you have Java enabled in the preferences, otherwise it won't work.
|
|
||
Comment 22•23 years ago
|
||
|
|
||
Comment 23•23 years ago
|
||
|
|
||
Comment 24•23 years ago
|
||
|
|
||
Comment 25•23 years ago
|
||
|
|
||
Comment 26•23 years ago
|
||
Ok here is our bugreport :-)
It is so that you have right with the adding and removing of applets. But in the
other hand, we are also not so wrong... ;-)
Please see the demo on http://technetos.ch:8080/technetos/applet.html. I can
test this stuff at monday with mac os 8/9 and maybe macX.
The report does also include mayscript/liveconnect stuff. This may be not the
right bug to report this, but when you are going to dyn. adding applets, you are
not so far away of using liveconect :-)
|
|
||
Comment 27•23 years ago
|
||
Olaf, thanks for the quick response!
I'm gonna go ahead and mark this bug fixed because the creation of applets works
fine. I tried your testcase on 0.9.8 and I did not see any problem removing the
applet. The LiveConnect/mayscript issue does not belong to the DOM, there is a
special LiveConnect component in bugzilla. We would really appreciate it if you
could file a new bug under that component.
Also I don't really know what you mean by "buttons freeze after removing the
applet". They still work fine here. However you just exposed a new bug which is
that when you remove an element from the document using the DOM, it's still
available in the document object. That means that your check for
if(document.app==null) will evaluate to false and a new applet will not be
created after you clicked on the "Remove Applet" button. I will file that bug.
Thanks for all!
|
|
||
Comment 28•23 years ago
|
||
Hi,
Here is a short description of the freeze problem.
Adding the applet by clicking on the <add applet button>.
The applet will be successfully added to the body.
Removing the applet by clicking the <remove applet button>.
The <remove applet button> does have the focus now, and no other button can now
have the focus or can be pressed.
There is no way to exit the site. The browser itself does not freeze, but it is
also not possbile to switch to an other url.
You can only shutdown/quit, but then the mozilla.exe is still remaining in ram.
This may be so, because I turned on the feature "let mozilla exist in ram...:-)".
After this, it is not possible to open a new mozilla window. I need to kill
explicitly the mozilla proccess, so that mozilla can restart.
The bug has allways the same behaviour on any tested win32 station.
WinNT4Sp6
W2k
Win98
I do not have time today for testing on mac (need to setup moz and so), but
tomorrow it should go.
More information will follow, as soon as I get time....
|
|
||
Comment 29•23 years ago
|
||
It works on mac 8/9 os with moz.0.9.8, and there is no freeze problem like it is
on win32 platforms.
But the document.app does behave like you already found it out.
Tom/Olaf
|
|
||
Comment 30•23 years ago
|
||
Marking FIXED. Olaf, if you're still seeing the freeze on Win32 in a latest
build, could you please file a new bug? Thanks in advance.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
|
|
||
Comment 31•23 years ago
|
||
thx for the fix:-) its working now for me too. (build 2002031708).
all other issues are already on the way (in other bugsreports)
Component: DOM: HTML → DOM: Core & HTML
QA Contact: stummala → general
You need to log in
before you can comment on or make changes to this bug.
Description
•