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)
Core Graveyard
File Handling
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: davide.ficano, Unassigned)
References
Details
(Keywords: stackwanted)
Attachments
(1 file)
1.82 KB,
application/javascript
|
Details |
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
Reporter | ||
Comment 1•14 years ago
|
||
Reporter | ||
Comment 2•14 years ago
|
||
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
Reporter | ||
Updated•14 years ago
|
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
Reporter | ||
Comment 4•14 years ago
|
||
Crash report ids bp-f613f8a1-6760-4bba-98cf-7cbd72100313 bp-6507e757-bf93-49b7-b7a4-1818e2100313
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
Comment 6•14 years ago
|
||
> 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
Reporter | ||
Comment 7•14 years ago
|
||
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•14 years ago
|
||
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...
Reporter | ||
Comment 9•14 years ago
|
||
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•14 years ago
|
||
> 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.
Assignee | ||
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•