Closed Bug 3584 Opened 27 years ago Closed 26 years ago

document.written nsDocuments need a valid URL.

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 3387

People

(Reporter: morse, Assigned: nisheeth_mozilla)

References

(
URL
)

Details

Following content causes browser to crash when button is pressed. Stack trace appears after the content. This is currently a blocking problem for development of client-wallet. <HTML> <HEAD> <SCRIPT> button_frame = 1; function loadFrames(){ top.frames[button_frame].document.open(); top.frames[button_frame].document.write( "<FORM name=buttons method=post>" + "<INPUT type=BUTTON value=OK onclick=parent.clicker()>" + "</FORM>" ); top.frames[button_frame].document.close(); } function clicker(){ top.frames[button_frame].document.buttons.submit(); } </SCRIPT> </HEAD> <FRAMESET ROWS = 50,50 onLoad=loadFrames()> <FRAME SRC=about:blank> <FRAME SRC=about:blank> </FRAMESET> <NOFRAMES> <BODY> <BR> </BODY> </NOFRAMES> </HTML> NTDLL! 77f76148() net_check_file_type(_ActiveEntry * 0x0145aae0) line 281 + 20 bytes net_ProcessFile(_ActiveEntry * 0x0145aae0) line 1291 + 9 bytes net_FileLoad(_ActiveEntry * 0x0145aae0) line 1273 + 9 bytes NET_GetURL(URL_Struct_ * 0x0145a6d0, int 102, MWContext_ * 0x0145a950, void (URL_Struct_ *, int, MWContext_ *)* 0x004b2d6b bam_exit_routine(URL_Struct_ *, int, MWContext_ *)) line 3034 + 12 bytes nsNetlibService::OpenStream(nsNetlibService * const 0x012fc1b0, nsIURL * 0x0145a330, nsIStreamListener * 0x0145a2b0) line 433 + 20 bytes nsDocumentBindInfo::Bind(nsIURL * 0x0145a330, nsIStreamListener * 0x00000000) line 1486 + 23 bytes nsDocumentBindInfo::Bind(const nsString & {...}, nsIPostData * 0x0145abf0, nsIStreamListener * 0x00000000) line 1460 + 16 bytes nsDocLoaderImpl::LoadDocument(nsDocLoaderImpl * const 0x013faed0, const nsString & {...}, char * 0x018b78e0, nsIContentViewerContainer * 0x013fa900, nsIPostData * 0x0145abf0, nsISupports * 0x00000000, nsIStreamObserver * 0x013fa91c, nsURLReloadType nsURLReload, const unsigned int 0) line 914 + 21 bytes nsWebShell::DoLoadURL(const nsString & {...}, char * 0x018b78e0, nsIPostData * 0x0145abf0, nsURLReloadType nsURLReload, const unsigned int 0) line 1322 nsWebShell::LoadURL(nsWebShell * const 0x013fa900, unsigned short * 0x0145acd0, char * 0x018b78e0, nsIPostData * 0x0145abf0, int 1, nsURLReloadType nsURLReload, const unsigned int 0) line 1403 + 28 bytes nsWebShell::LoadURL(nsWebShell * const 0x013fa900, unsigned short * 0x0145acd0, nsIPostData * 0x0145abf0, int 1, nsURLReloadType nsURLReload, const unsigned int 0) line 1255 nsWebShell::HandleLinkClickEvent(nsIContent * 0x0144eb30, nsLinkVerb eLinkVerb_Replace, unsigned short * 0x0145acd0, unsigned short * 0x10028f40, nsIPostData * 0x0145abf0) line 1861 OnLinkClickEvent::HandleEvent() line 1690 HandlePLEvent(OnLinkClickEvent * 0x0145ac30) line 1703 PL_HandleEvent(PLEvent * 0x0145ac30) line 478 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x012dd4c0) line 439 + 9 bytes _md_EventReceiverProc(void * 0x00020300, unsigned int 49305, unsigned int 0, long 19780800) line 822 + 9 bytes USER32
This is a regression. Same test worked fine with a tree that was pulled about a week ago.
Assignee: dp → spence
Summary: Submitting form causes browser to crash → [BLOCK]wallet - Submitting form causes browser to crash
Target Milestone: M3
is this all forms?
No, it's not all forms because I am able to submit forms on other pages with no trouble. I don't know what it is about this particular content that causes the crash.
Summary: [BLOCK]wallet - Submitting form causes browser to crash → [BLOCK]wallet -Submitting some forms causes browser to crash
Steve, can you work on simplifying the url and publishing it in say http://webgroup/xpnav/test thanks for the help steve.
The content I cited in this messgae has already been simplified as much as I could and still demonstrate the crash. Per your request, I have now published it at http://webgroup/xpnav/test/3584.html. I just tried it and with a build from this morning it now gives different symptoms than what I previously reported (somebody must have changed something). Instead of crashing it now gives a javascript error. Hmmm! It's still blocking wallet in any event.
Status: NEW → ASSIGNED
Assignee: spence → vidur
Status: ASSIGNED → NEW
i took a look at this. it looks like js is not properly creating the form, and thus no url is obtained in layout. the null url is passed to netlib in NS_MakeAbsoluteURL() and crashed there. as steve said, the symptoms have changed, but i still believe js/dom is doing something wrong. passing to vidur.
Let's not lose site of the original crash. I doubt that this has been fixed yet but with this new behavior we can't even get far enough to find out. The original crash occured when the button was pressed and now we don't even get to see a button. What I'm trying to say is that once we get past this new javascript error, we mustn't close out this bug until we can also successfully press the button.
Assignee: vidur → morse
The bug that's causing the JavaScript error is actually a parser problem that RickG is aware of and fixing for M3. The problem is that the SCRIPT tag in the HEAD is incorrectly forcing a BODY to be opened and the frameset is ignored. I'm reassigning the bug to Steve since the original bug is still relevant. Steve should coordinate with RickG to find out when his test case will work.
Assignee: morse → rickg
Reassigning to rickg as per vidur, this is a parser bug.
I have another test that is not crashing but rather is giving a javascript error -- namely "top.frames[0] has no properties". This looks like a different bug to me but Vidur assures me that it is another instance of the same thing and that the fix that he and rickg have (in CNavDTD.cpp) will fix it. Indeed Vidur put that fix onto my machine and it fixed this javascript error bug. It is important that this fix get into M3 because it is blocking part of the wallet functionality. Here's the example that is currently giving the javascript error. <HTML> <HEAD> <SCRIPT> function loadFrames(){ top.frames[0].document.open(); top.frames[b0].document.close(); } </SCRIPT> </HEAD> <FRAMESET onLoad=loadFrames()> <FRAME SRC=about:blank> <FRAME SRC=about:blank> </FRAMESET> <NOFRAMES> <BODY> <BR> </BODY> </NOFRAMES> </HTML> To see where this is blocking wallet in M3, do edit/wallet/wallet-contents. If you can get to a dialog window, then you've fixed the problem.
Assignee: rickg → nisheeth
Checked in a fix yesterday that would take care of the JS error. However, a crash is happening on clicking the "OK" button. This could be a problem with the webshell. Assigning the bug to nisheeth. Adding myself to the CC list. Here is the stack trace: NTDLL! 77f76148() nsDebug::PreCondition(char * 0x01957364, char * 0x019573a8, char * 0x019573b8, int 380) line 120 + 13 bytes nsCOMPtr<nsIURL>::operator->() line 380 + 34 bytes nsWebShell::DoLoadURL(const nsString & {"file://F:/Parser_Bugs/wallet.htm"}, char * 0x019589a0, nsIPostData * 0x013ebed0, nsURLReloadType nsURLReload, const unsigned int 0) line 1309 + 17 bytes nsWebShell::LoadURL(nsWebShell * const 0x0138f560, unsigned short * 0x013eb890, char * 0x019589a0, nsIPostData * 0x013ebed0, int 1, nsURLReloadType nsURLReload, const unsigned int 0) line 1441 + 28 bytes nsWebShell::LoadURL(nsWebShell * const 0x0138f560, unsigned short * 0x013eb890, nsIPostData * 0x013ebed0, int 1, nsURLReloadType nsURLReload, const unsigned int 0) line 1281 nsWebShell::HandleLinkClickEvent(nsIContent * 0x013e1cc0, nsLinkVerb eLinkVerb_Replace, unsigned short * 0x013eb890, unsigned short * 0x10029010, nsIPostData * 0x013ebed0) line 1919 OnLinkClickEvent::HandleEvent() line 1748 HandlePLEvent(OnLinkClickEvent * 0x013ebf10) line 1761 PL_HandleEvent(PLEvent * 0x013ebf10) line 476 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x0126f230) line 437 + 9 bytes _md_EventReceiverProc(void * 0x01fa0404, unsigned int 49397, unsigned int 0, long 19329584) line 803 + 9 bytes USER32! 77e71250()
URL: http://webgroup/xpnav/test/3584.html
Status: NEW → ASSIGNED
Adding URL to bug...
I've checked in a fix. Change coded by vidur. Reviewed by me. Document.written documents now get a default "about:blank" url assigned to them. Steve just tried to verify the fix in his build and said that he is crashing in some other place, but the current test case works. He is going to isolate the new problem, create a new minimal test case, and add everything to this bug.
Target Milestone: M3 → M4
We need to change the hardcoded URL, "about:blank", to be the URL of the document that does the document.write. Setting milestone to M4.
Summary: [BLOCK]wallet -Submitting some forms causes browser to crash → document.written nsDocuments need a valid URL.
Clearing blocked status from summary and updating it to better reflect what we know.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 3387 ***
Status: RESOLVED → VERIFIED
Verified Dup
Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)
Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.
You need to log in before you can comment on or make changes to this bug.