Closed Bug 552193 Opened 14 years ago Closed 14 years ago

[@ nsDocShell::OnStateChange] when creating and using a docshell without calling nsIBaseWindow.create

Categories

(Core Graveyard :: File Handling, defect)

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: davide.ficano, Unassigned)

References

Details

(Keywords: stackwanted)

Attachments

(1 file)

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
The problem occurs with Firefox 3.7a2 and a3

I don't know how to set this information on bug data, please apologize me
Version: unspecified → Trunk
Summary: nsIWebPageDescriptor.loadPage craches → nsIWebPageDescriptor.loadPage crashes
https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report

please provide a stack trace.
Component: General → File Handling
Keywords: stackwanted
Product: Firefox → Core
QA Contact: general → file-handling
Version: Trunk → 1.9.1 Branch
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.
Blocks: 482985
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: nsIWebPageDescriptor.loadPage crashes → [@ nsDocShell::OnStateChange] when creating and using a docshell without calling nsIBaseWindow.create
Version: 1.9.1 Branch → Trunk
> 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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
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
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...
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
> 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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: