1408451 - Try logging to web console (not browser console) when blocking toplevel data URI navigations

Status: RESOLVED FIXED

(Core :: DOM: Security, enhancement, P1)

Description

[Christoph Kerschbaumer [:ckerschb}]

I think we can query the actual document where the load occurs and use that document to provide context so the logging appears on the web console instead of the browser console.

Comment 1

[Christoph Kerschbaumer [:ckerschb}]

Attachment: bug_1408451_data_log_web_console.patch

Boris, within docshell we can use the 'current document' to log to the web console (instead of the browser console). The redirect case is a little tricky because we loose the context (and hence the document) during serialization. In the end, the redirect case still logs to the browser console :-( but logging to the web console in the regular load/block case is definitely an improvement.

If you prefer, we could query the windowId from the loadInfo, do FormatLocalizedString and friends ourselves within AllowTopLevelNavigationToDataURI() and call nsContentUtils::ReportToConsoleByWindowID() instead of ReportToConsole().

Comment 2

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8918828 [details] [diff] [review]
bug_1408451_data_log_web_console.patch

Seems OK.  This is logging based on the "doc we would overwrite", not the "doc that started the load", but better than nothing.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8719c44ef3e2
Log to web console when blocking toplevel data: URI navigations. r=bz

Comment 4

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/8719c44ef3e2