For Aurora users as part of the customization approach we should change view source to open in a tab by default.

Bug 1072181 should be done for devedition.

I don't think this should be devedition only. It's been discussed many times before. We could just load view-source:%URL in a new tab. But we'd lose the "Edit" and "View" menus (and I don't think it's a real problem). So that would be a quick fix. Another option is to load the source in codeeditor, in read-only mode. More work.

Maybe integrate this extension https://addons.mozilla.org/it/firefox/addon/web-page-to-source-code-vic/?src=api

Maybe some ideas from this extension also will be useful: https://addons.mozilla.org/en-US/firefox/addon/more-in-content-ui-plus/

maybe we could provide both open source in tab and in new window. But as most browsers are opening source in a tab, I prefer to set opening in a tab as the default behaviour (and default to Command + U).

From consolidating the `viewSource` methods (debugger, scratchpad, style editor, with fall backs to "view-source:") in bug 1134778, this will be pretty straight forward to implement for anything in devtools that opens a source (clicking on a source in webconsole, profiler, etc.) Now if this is for changing the context menu for view source, then that's something else.

(In reply to Jordan Santell [:jsantell] [@jsantell] from comment #7) ... > Now if this is for changing the context menu for view source, then that's > something else. The uservoice issue is here: https://ffdevtools.uservoice.com/admin/forums/246087-firefox-developer-tools-ideas/suggestions/5895550-view-source-in-a-tab I've always considered this use case to cover "right click -> view source" as well.

The code that generates the view-source content is located here: `parser/html/nsHtml5Highlighter.cpp`. I would recommend to build another protocol handler than `view-source:` to start. Maybe just `view-source2:`. Then just load a read-only version of CM.

Ok -- that sounds straight forward then. Why do we need another protocol? We can just open up the same url `view-source:${url}` in a new tab, which is way easier than the magic needed for the same url in a new window -- what am I missing?

(In reply to Jordan Santell [:jsantell] [@jsantell] from comment #10) > Ok -- that sounds straight forward then. > > Why do we need another protocol? We can just open up the same url > `view-source:${url}` in a new tab, which is way easier than the magic needed > for the same url in a new window -- what am I missing? Yes. We could just do that. I was suggesting to use codemirror to have a richer view-source. That would require a new implementation of view-source. But that can happen in a different bug.

(In reply to Jeff Griffiths (:canuckistani) from comment #8) > (In reply to Jordan Santell [:jsantell] [@jsantell] from comment #7) > ... > > Now if this is for changing the context menu for view source, then that's > > something else. > > The uservoice issue is here: > > https://ffdevtools.uservoice.com/admin/forums/246087-firefox-developer-tools- > ideas/suggestions/5895550-view-source-in-a-tab > > I've always considered this use case to cover "right click -> view source" > as well. This should be two different bugs then. One for the toolbox links and one for the main context menu filed in Firefox::Menus. In fact, I see Bug 1067325, that looks like it's covering the ctrl+u / context menu functionality.

Once bug 1134778 lands, all toolbox view source features will use the same base, which falls back to "view-source:" if unable to view it in another tool, and currently using gViewSourceUtils for this. Talking to jryans, seems that in bug 1067325, gViewSourceUtils will change, meaning this may "Just Work" after that lands as well.

The necessary toolbox changes landed as part of bug 1067325.

All my gratitude, this was highly annoying :-)