Closed Bug 1216839 Opened 5 years ago Closed 5 years ago

Crash when loading icon from android:// protocol with xhr

Categories

(B2GDroid Graveyard :: General, defect)

x86_64
Linux
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: fabrice, Unassigned)

References

Details

Attachments

(1 file)

Fallout of bug 1182571

That happens when the getIcon() code at http://mxr.mozilla.org/mozilla-central/source/dom/apps/Webapps.jsm#4338 is loading icons for android apps. We use urls like android://icon/com.android.contacts for these.

Jonas, is there anything special I should look at in the android: protocol handler or channel implementation?
Where is it implemented? Does the channel that it returns an AsyncOpen2 implementation? If it's implemented in C++ then it should simply look like:

http://mxr.mozilla.org/mozilla-central/source/netwerk/base/nsBaseChannel.cpp#678

If it's implemented in JS then it should look like:

http://mxr.mozilla.org/mozilla-central/source/b2g/components/ActivityChannel.jsm#57
http://mxr.mozilla.org/mozilla-central/source/b2g/components/ActivityChannel.jsm#15
I.e. the Channel should have an asyncopen2 implementation like the ones linked to above. The channel also needs to support the loadInfo getter/setter.

The protocol handler needs to have a newChannel2 implementation. This is the same as newChannel, but it also receives a loadInfo which it needs to set on the created channel.

Debug builds will assert/crash if you do any of this stuff wrong.
The android channel at http://mxr.mozilla.org/mozilla-central/source/widget/android/nsAndroidProtocolHandler.cpp#67 inherits from nsBaseChannel and provides OpenContentStream() that is used in nsBaseChannel::BeginPumpingData()
I haven't checked yet what nsContentSecurityManager::doContentSecurityCheck() returns in this case.
Hrm... both the channel and the protocol handler looks correct. I think we'll need a stack.
Stack trace of the crash:
(gdb) bt
#0  nsBaseChannel::GetOriginalURI (this=<optimized out>, aURI=0xa346b120) at /home/fabrice/dev/b2g-inbound/netwerk/base/nsBaseChannel.cpp:431
#1  0x97fdd068 in NS_GetFinalChannelURI (channel=0x8595584c, uri=0xa346b120) at /home/fabrice/dev/b2g-inbound/netwerk/base/nsNetUtil.cpp:1580
#2  0x98af9b3a in nsContentSecurityManager::doContentSecurityCheck (aChannel=0x8595584c, aInAndOutListener=...)
    at /home/fabrice/dev/b2g-inbound/dom/security/nsContentSecurityManager.cpp:340
#3  0x97fd117c in nsBaseChannel::AsyncOpen2 (this=0x85955820, aListener=<optimized out>) at /home/fabrice/dev/b2g-inbound/netwerk/base/nsBaseChannel.cpp:681
#4  0x985ce60e in nsXMLHttpRequest::Send (this=0x89eaec00, aVariant=<optimized out>, aBody=...) at /home/fabrice/dev/b2g-inbound/dom/base/nsXMLHttpRequest.cpp:2917
#5  0x9881b066 in Send (aBody=..., this=<optimized out>) at /home/fabrice/dev/b2g-inbound/dom/base/nsXMLHttpRequest.h:422
#6  Send (aRv=..., this=<optimized out>) at /home/fabrice/dev/b2g-inbound/dom/base/nsXMLHttpRequest.h:439
#7  mozilla::dom::XMLHttpRequestBinding::send (cx=0xa3097300, obj=..., self=0x89eaec00, args=...)
    at /home/fabrice/dev/builds/obj-b2gdroid/dom/bindings/XMLHttpRequestBinding.cpp:602
#8  0x98917e64 in mozilla::dom::GenericBindingMethod (cx=0xa3097300, argc=<optimized out>, vp=<optimized out>)
    at /home/fabrice/dev/b2g-inbound/dom/bindings/BindingUtils.cpp:2691

Calling SetURI() implemented in nsBaseChannel.h ensure that we initialize everything properly.
Attachment #8677088 - Flags: review?(jonas)
Ah, yes, makes sense that you have to call SetURI during initialization.
https://hg.mozilla.org/mozilla-central/rev/0f821c314396
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.