Closed Bug 624763 Opened 9 years ago Closed 8 years ago
View selection source causes event handlers in document to fire
100 bytes, text/html
283 bytes, text/html
4.85 KB, patch
|Details | Diff | Splinter Review|
I'm not sure if Networking is the right component or if this is even a bug we'd fix, but I wanted to file it anyway to investigate. When you have event-handlers on DOM elements like the one in the testcase, e.g. <img src="http://www.mozilla.com/favicon.ico" onload="alert('load')"> Selecting the content and viewing selection source causes the event handlers to fire. Doing a normal view source does not trigger the event handlers. Is this just a side effect of having to reparse the DOM tree to figure out which portion is selected? Is it an effect that we should try to prevent?
Adding the original reporter and hiding while we determine if this is a serious issue.
> Is this just a side effect of having to reparse the DOM tree What the heck does it mean to "reparse the DOM tree"? ;) This isn't a core issue. viewPartialSourceForSelection in viewPartialSource.js has this gem: 123 // clone the fragment of interest and reset everything to be relative to it 124 // note: it is with the clone that we operate/munge from now on 125 ancestorContainer = ancestorContainer.cloneNode(true); Cloning an image node will start the image load on the clone, of course. The right way to do this is to have a data document (e.g. created with createDocument) and _import_ the fragment into that. That way the normal data document content policy will prevent network access from elements in the clone (and event handlers on them couldn't run anyway, since a data document has no scripting environment).
Component: Networking → View Source
Product: Core → Toolkit
QA Contact: networking → view.source
A Boris indicated, the event handler is run in the original document and thus can't do anything it hadn't already been able to do to you. This is a bug, but not a security concern.
(In reply to comment #3) > (and event handlers on them couldn't run anyway, since a data document has no > scripting environment). This is not quite true. Data documents do have script handling object, if the document, which' implementation was used for createDocument has as script handling object. But onfoo attributes don't map to event listeners on data documents.
Unfortunately, a document created via document.implementation is not marked as loaded as data, and has working inline event handlers... so that approach doesn't work. We could really use a way to say "clone this DOM bit as data"...
(In reply to Boris Zbarsky (:bz) from comment #6) > Unfortunately, a document created via document.implementation is not marked > as loaded as data Really? I thought they were marked as data documents. Has something regressed that.
As far as I see, nsContentUtils::CreateDocument does create a data document, and document.implementation uses that.
Ah, indeed. I should have looked more carefully at _which_ document was the ownerDocument when the security check passed. I just needed to make more changes to the view-source code. Fix coming up.
Assignee: nobody → bzbarsky
Whiteboard: [need review]
Attachment #562355 - Flags: review?(Olli.Pettay) → review+
Priority: -- → P2
Whiteboard: [need review]
Target Milestone: --- → mozilla9
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.