Bug 590404 fixed a crash regarding this, but the code is trying to have about protocol handler build an uri for the element, and that fails. See https://bugzilla.mozilla.org/show_bug.cgi?id=590404#c4
Yeah, this is a fundamental problem with representing object references as URIs and not all of our URIs having a "ref". We have numerous old bugs on this (various SVG resource stuff also doesn't work, nor does embedding XBL inline, etc, etc).
Fwiw, any custom protocol handler that uses an nsStandardURL as the URI will work.
How hard would it be to fix this? Would this involve some bigger refactoring?
There was a need for bigger refactoring, but dholbert did that at some point. In fact, this may Just Work now. Certainly data:text/html;charset=utf-8,<!DOCTYPE html>%0D%0A<html>%0D%0A<head>%0D%0A<body>%0D%0A<div style%3D"background-image%3A -moz-element(%23foo)%3B height%3A 100px">%0D%0A<%2Fdiv>%0D%0A<div id%3D"foo">%0D%0A aaa%0D%0A<%2Fdiv>%0D%0A<%2Fbody>%0D%0A<%2Fhtml>%0D%0A works fine for me.
I guess for about: the protocol handler would need to be updated to deal.
Yeah, I was referring especially to about:. What would I need to change in the about: protocol handler?
You'd need to change NewURI to handle this case (see what nsDataHandler::NewURI does), and change whatever code assumes that the only thing after the ':' is the module name. I _think_ that might be the empty set; NS_GetAboutModuleName does the right thing. But worth double-checking.
I was about to post http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/data/nsDataHandler.cpp#108 but Boris has been faster :D
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258