Open Bug 686264 Opened 14 years ago Updated 5 years ago

incorrect href value in html within content-editable with source having absolute uri pointing to host and page having base attribute set

Categories

(Core :: DOM: Editor, defect, P5)

Product:
Core
Component:
DOM: Editor
Version:
5 Branch
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: hsalkaline, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.30 (KHTML, like Gecko) Ubuntu/11.04 Chromium/12.0.742.112 Chrome/12.0.742.112 Safari/534.30 Steps to reproduce: make a page with following html #link must point to same host as one where the page is located <head> <base href="http://hostname/some/base/dir/" /> </head> <body> <a id="link" href ="http://hostname/test.html">link</a> <div id="content" contenteditable="true"> <div style="border: solid 1px black; width:300px; height:300px;"> some text </div> </div> </body> open page select link containg "link" text with mouse click copy in context menu click into div with id=content click paste from context menu Actual results: html inside the div with content-editable=true contains <a href="../../../test.html" _moz_dirty="">link</a> Expected results: html inside the div with content-editable=true should contain <a href ="http://hostname/test.html">link</a>
Component: General → Editor
Product: Firefox → Core
QA Contact: general → editor
Alexey, which version of Firefox did you test this with? Aryeh, this is probably something worth handling in the spec...
Currently the spec doesn't handle copy/paste at all. I assume the right way to fix this would be that when you copy HTML, all URLs should be made absolute. But it's nonstandard for now.
This is also an issue for the "inserthtml" command, so I think it needs to be specified in the spec.
Firefox 5.0, Ubuntu 11.04
I don't think the issue is with paste/insertHTML, it's with cut/copy. By the time you get to paste or insertHTML, you don't know what the original page's URL was, so you can't do anything about relative URLs in attributes. You want to resolve relative URLs at cut/copy time. Also, my philosophy with insertHTML is that it should do only minimal cleanup. I'm intending it to be used as a low-level tool for authors to insert exactly the markup they want. I don't think it should do things like strip script tags, although I'll update the spec to require that if browsers actually do it in practice (do they?).
(In reply to Aryeh Gregor from comment #5) > I don't think the issue is with paste/insertHTML, it's with cut/copy. By > the time you get to paste or insertHTML, you don't know what the original > page's URL was, so you can't do anything about relative URLs in attributes. > You want to resolve relative URLs at cut/copy time. There is also the corresponding case of injecting relative URL hrefs, but I guess we can make it up to the authors to inject stuff which makes sense. I agree that the situation with paste is a bit different since the web page author doesn't know a lot about what things are going to be pasted (except with the "aftereditaction" event...) > Also, my philosophy with insertHTML is that it should do only minimal > cleanup. I'm intending it to be used as a low-level tool for authors to > insert exactly the markup they want. I don't think it should do things like > strip script tags, although I'll update the spec to require that if browsers > actually do it in practice (do they?). Gecko doesn't, and it doesn't really make sense to do so. Any script using inserthtml to inject things like script tags can just set the innerHTML property and do that directly, so handling those stuff especially in the case of inserthtml is not useful.

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority and severity.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.