Last Comment Bug 552193 - [@ nsDocShell::OnStateChange] when creating and using a docshell without calling nsIBaseWindow.create
: [@ nsDocShell::OnStateChange] when creating and using a docshell without call...
Status: RESOLVED INVALID
: stackwanted
Product: Core Graveyard
Classification: Graveyard
Component: File Handling (show other bugs)
: Trunk
: All All
: -- critical (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks: 482985
  Show dependency treegraph
 
Reported: 2010-03-13 08:59 PST by Davide Ficano
Modified: 2016-06-22 12:16 PDT (History)
3 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
The code used to demonstrate the regression (1.82 KB, application/javascript)
2010-03-13 09:00 PST, Davide Ficano
no flags Details

Description Davide Ficano 2010-03-13 08:59:44 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; it; rv:1.9.1.8) Gecko/20100214 Ubuntu/9.10 (karmic) Firefox/3.5.8
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; it; rv:1.9.1.8) Gecko/20100214 Ubuntu/9.10 (karmic) Firefox/3.5.8

Calling nsIWebPageDescriptor.loadPage from Javascript code Firefox craches.

In attach the code to reproduce the problem

Reproducible: Always

Steps to Reproduce:
Use the test code in attach
Comment 1 Davide Ficano 2010-03-13 09:00:57 PST
Created attachment 432336 [details]
The code used to demonstrate the regression
Comment 2 Davide Ficano 2010-03-13 09:02:47 PST
The problem occurs with Firefox 3.7a2 and a3

I don't know how to set this information on bug data, please apologize me
Comment 3 timeless 2010-03-13 11:06:28 PST
https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report

please provide a stack trace.
Comment 5 timeless 2010-03-14 01:17:49 PST
bug 517768 comment 7

5591 if (NS_SUCCEEDED(mPrefs->GetBoolPref("ui.use_activity_cursor", &tmpBool))
5592 && tmpBool) { 

Signature	nsDocShell::OnStateChange(nsIWebProgress*, nsIRequest*, unsigned int, unsigned int)
UUID	f613f8a1-6760-4bba-98cf-7cbd72100313
Time 	2010-03-13 23:33:50.525367
Uptime	28
Last Crash	87 seconds before submission
Product	Firefox
Version	3.7a2
Build ID	20100228165829
Branch	1.9.3
OS	Windows NT
OS Version	5.1.2600 Service Pack 3
CPU	x86
CPU Info	GenuineIntel family 6 model 15 stepping 11
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0x0
User Comments	[Bug 552193] nsIWebPageDescriptor.loadPage crashes
Processor Notes 	
Related Bugs

FIXED Bug 517768 RESOLVED crash with view page source and external editor [@nsDocShell::OnStateChange(nsIWebProgress*, nsIRequest*, unsigned int, unsigned int) ]

Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsDocShell::OnStateChange 	docshell/base/nsDocShell.cpp:5592
1 	xul.dll 	nsDocLoader::FireOnStateChange 	uriloader/base/nsDocLoader.cpp:1314
2 	xul.dll 	nsDocLoader::doStartDocumentLoad 	uriloader/base/nsDocLoader.cpp:835
3 	xul.dll 	nsDocLoader::OnStartRequest 	uriloader/base/nsDocLoader.cpp:546
4 	xul.dll 	nsLoadGroup::AddRequest 	netwerk/base/src/nsLoadGroup.cpp:595
5 	xul.dll 	nsViewSourceChannel::AsyncOpen 	netwerk/protocol/viewsource/src/nsViewSourceChannel.cpp:229
6 	xul.dll 	nsURILoader::OpenURI 	uriloader/base/nsURILoader.cpp:840
7 	xul.dll 	nsDocShell::DoChannelLoad 	docshell/base/nsDocShell.cpp:8636
8 	xul.dll 	nsDocShell::DoURILoad 	docshell/base/nsDocShell.cpp:8482
9 	xul.dll 	nsDocShell::InternalLoad 	docshell/base/nsDocShell.cpp:8172
10 	xul.dll 	nsDocShell::LoadHistoryEntry 	docshell/base/nsDocShell.cpp:9649
11 	mozcrt19.dll 	free 	obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:6017
12 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102
13 	xul.dll 	XPCWrappedNative::CallMethod 	js/src/xpconnect/src/xpcwrappednative.cpp:2727

Please see bug 517768 for an explanation of how to work around this.

bz: this really sucks, we obviously broke something that was used by more than our own private code.
Comment 6 Boris Zbarsky [:bz] (Out June 25-July 6) 2010-05-27 10:40:13 PDT
> we obviously broke something that was used by more than our own private code.

Yes, but it SHOULDN'T HAVE BEEN.  Creating docshells by contract like that has never been supported (and we should remove the contract, honestly), and has never behaved correctly.  Most importantly, it's trivial to end up with security bugs that way.
Comment 7 Davide Ficano 2010-06-23 02:02:40 PDT
Any news about this bug?

I've downloaded the version 3.7a6pre 64bit for Max and it is present.

The status is 'resolved' but I continue to see firefox crashing.

The code in attach is always valid to test the bug
Comment 8 Boris Zbarsky [:bz] (Out June 25-July 6) 2010-06-23 09:05:36 PDT
The code in the attachment is not expected to work, and doing what that code is doing is not supported.  To use a docshell you have to properly initialize it first, and the attached code is not doing that.  Note that the bug is resolved "invalid", which means that the bug is not in our code...
Comment 9 Davide Ficano 2010-06-23 09:10:12 PDT
Is the correct code at

http://mxr.mozilla.org/mozilla-central/source/toolkit/components/viewsource/content/viewSourceUtils.js#144

the correct way to initialize the webshell

I don't find any clear documentation
Comment 10 Boris Zbarsky [:bz] (Out June 25-July 6) 2010-06-23 09:31:23 PDT
> Is the correct code at ... the correct way to initialize the webshell

"Yes".

> I don't find any clear documentation

That's because fundamentally the use of a docshell outside an actual frame element is not supported, period.  It might work.  It might not.  If you're not _very_ careful your code will likely be exploitable.

Note You need to log in before you can comment on or make changes to this bug.