It would be great to be able to interact with links from the markup view. We could automatically convert these URLs into links that open in a new tab on click, or we could allow a right click -> "Open in new tab" feature for these attributes. Also, a "Copy Link Location" action on right click like what happens in the main browser context menu would be great.
iirc this used to work in nightly for a while (at least for images), but we decided to remove the output-parser parsing from the markup-view as it was having some weird edge cases with some attributes (see bug 952511).
FWIW firebug allows to cmd/ctrl click on the links to open in a new tab. A normal click just turns the attribute the link is in into edit mode.
(In reply to Patrick Brosset [:pbrosset] [:patrick] from comment #3) > FWIW firebug allows to cmd/ctrl click on the links to open in a new tab. A > normal click just turns the attribute the link is in into edit mode. That sounds great. (In reply to Patrick Brosset [:pbrosset] [:patrick] from comment #1) > iirc this used to work in nightly for a while (at least for images), but we > decided to remove the output-parser parsing from the markup-view as it was > having some weird edge cases with some attributes (see bug 952511). Should we handle this without the output parser, or do you think the related bugs may be fixed by now?
The problem we were having with the output-parser when applied to the markup-view is that it tried to change anything that resembled a color into a color swatch, without actually parsing the CSS. Due to this limitation we decided to use it only in the rule-view/computed-view to parse only property values (therefore decreasing the risks for incorrect parsing. We still had problems with font names though, which can take any names, see bug 977063). So I'm not in favor of using the output parser code as is for attributes in the markup-view. What we need is something that detects URLs (this helper could definitely go in the output-parser.js module by the way). It needs to be easy to use from any tool. Already one candidate outside the inspector is the web console (for instance, type 'document', the output contains the URL of the document which today isn't clickable). I think the helper should only really parse the input and detect URLs but not build the output markup with <a> links in it, because the behavior attached to clicking on the URL will depend on the panel (for instance in the inspector, I suspect we want to keep the click-to-edit pattern, but in the webconsole, click to open the link might be ok).
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 921102
Whiteboard: [devedition-40] → [polish-backlog]
You need to log in before you can comment on or make changes to this bug.