Closed Bug 841359 Opened 7 years ago Closed 7 years ago

Avoid logging script errors coming from private windows in the global error console

Categories

(Toolkit Graveyard :: Error Console, defect)

x86
macOS
defect
Not set
normal

Tracking

(firefox20+ verified, firefox21+ verified, firefox22+ verified)

RESOLVED FIXED
mozilla22
Tracking Status
firefox20 + verified
firefox21 + verified
firefox22 + verified

People

(Reporter: jdm, Assigned: Gavin)

References

(Blocks 1 open bug)

Details

(Keywords: verifyme)

Attachments

(1 file, 2 obsolete files)

+++ This bug was initially created as a clone of Bug #769298 +++

From comment 28:
This issue still reproduces on the current Aurora - 20130213042019 (checked on Windows 7 64bit and Mac OSX 10.8).

I open the Error Console (Ctrl+Shift+J), then go to an already opened private window. When loading a new page or reloading a page, all the corresponding warnings are displayed in the console.

---

I can reproduce this problem on nightly. I wonder if bug 818224 regressed it?
Yes, it was bug 818224. The check for chrome appears to work in most cases, but CSS errors that occur during the first parse of the style sheet are independent of any content JS, so they are considered chrome.
Assignee: nobody → josh
Bobby, the fix for bug 818224 wasn't good enough, unfortunately. We sometimes end up reporting errors for web content from the system principal (such as the initial CSS parse). Can you think of problems with this solution?
Attachment #714569 - Flags: review?(bobbyholley+bmo)
Comment on attachment 714569 [details] [diff] [review]
Avoid logging chrome errors from chrome:// sources in the global error console.

Boris, same question. Is this too brittle? Is there any better way?
Attachment #714569 - Flags: feedback?(bzbarsky)
(In reply to Josh Matthews [:jdm] from comment #2)
> We sometimes end up reporting errors for web content from the system principal
> (such as the initial CSS parse).

This doesn't sound right. Can you elaborate?
Attached file Sample CSS stack (obsolete) —
Here's an example of a CSS parser warning being thrown while the system principal is in effect.
Potential privacy issue, tracking.
So...

Assuming that warnings are always going to happen when the relevant page principal is on the stack is silly: we have warnings for CSS parsing, as you noted, network events of various sorts, etc, etc.

But you have a window here.  Why not just ask that window for its principal and check whether it's system, in cases when UsePrivateBrowsing() is true?
Attachment #714569 - Attachment is obsolete: true
Attachment #714569 - Flags: review?(bobbyholley+bmo)
Attachment #714569 - Flags: feedback?(bzbarsky)
Attached patch patchSplinter Review
Oh I see. Indeed, checking the window's principal seems like exactly what we want. I haven't tested this, but it compiles!
Attachment #714626 - Attachment is obsolete: true
Comment on attachment 714854 [details] [diff] [review]
patch

Tested and it works fine.
Attachment #714854 - Flags: review?(bzbarsky)
Assignee: josh → gavin.sharp
Comment on attachment 714854 [details] [diff] [review]
patch

r=me
Attachment #714854 - Flags: review?(bzbarsky) → review+
Comment on attachment 714854 [details] [diff] [review]
patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 818224
User impact if declined: Private URL leaks in the global error console.
Testing completed (on m-c, etc.): m-c
Risk to taking this patch (and alternatives if risky): Risk-free.
String or UUID changes made by this patch: None.
Attachment #714854 - Flags: approval-mozilla-beta?
Attachment #714854 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/c81af89d1e73
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
Attachment #714854 - Flags: approval-mozilla-beta?
Attachment #714854 - Flags: approval-mozilla-beta+
Attachment #714854 - Flags: approval-mozilla-aurora?
Attachment #714854 - Flags: approval-mozilla-aurora+
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Firefox/20.0 (20130227063501)

When only working in a private window, warnings are no longer displayed in the Error console. Messages and error are displayed though:
-when opening a new private window I got this message in the error console:
OpenGL LayerManager Initialized Succesfully.
Version: 2.1 ATI-1.0.15
Vendor: ATI Technologies Inc.
Renderer: ATI Radeon HD 6630M OpenGL Engine
FBO Texture Target: TEXTURE_2D

-when opening youtube.com I got this message:
Security Error: Content at https://www.google.ro/ may not load data from http://www.youtube.com/.

-when typing a string that ended in "\" in the URL bar and pressed Enter, I got this error:
Timestamp: 2/28/13 11:39:40 AM
Error: TelemetryStopwatch: key "FX_PAGE_LOAD_MS" was already initialized
Source File: resource://gre/modules/TelemetryStopwatch.jsm
Line: 53
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
QA Contact: ioana.budnar
(In reply to Simona B [QA] from comment #15)
> When only working in a private window, warnings are no longer displayed in
> the Error console.

Warning are displayed on Windows 8 64-bit and Ubuntu 12.10:
- when opening a new private window (File menu-> New Private Window),  I got several warnings like:
Timestamp: 02/28/2013 03:07:03 PM
Warning: Use of Mutation Events is deprecated. Use MutationObserver instead.
Source File: chrome://global/content/bindings/toolbar.xml
Line: 276

Timestamp: 02/28/2013 03:07:03 PM
Warning: XUL box for _moz_generated_content_before element contained an inline #text child, forcing all its children to be wrapped in a block.
Source File: chrome://browser/content/browser.js
Line: 10963
Those messages are (basically) fine. There are a couple points at play here:
* any error that points at a chrome:// URL does not leak any privacy-sensitive information, so they're fine
* "Security Error: Content at https://www.google.ro/ may not load data from http://www.youtube.com/" does leak information, but we have no way of detecting that from Gecko right now, since it doesn't provide a source URL. I'm going to file a bug to look into fixing this.
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Blocks: 846300
Flagging for verification against Firefox 21 and 22.
Keywords: verifyme
Verified fixed on Firefox Aurora 22.0a2: 20130410004014 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20130410 Firefox/22.0

Verified fixed on Firefox 21 beta 2: 20130408165307 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Firefox/21.0
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.