Closed Bug 799936 Opened 12 years ago Closed 10 years ago

GeckoConsole leaks Private Browsing URL's

Categories

(Firefox for Android Graveyard :: General, defect, P5)

ARM
Android
defect

Tracking

(firefox20 wontfix, firefox21 affected, firefox22 affected, fennec+)

RESOLVED WORKSFORME
Tracking Status
firefox20 --- wontfix
firefox21 --- affected
firefox22 --- affected
fennec + ---

People

(Reporter: aaronmt, Assigned: bnicholson)

References

Details

(New profile) i) New Private Browsing tab → (e.g, "http://www.digg.com") ii) Observe adb output ---- I/GeckoTabs( 2657): Got message: SessionHistory:New I/GeckoTabs( 2657): Got message: Content:LocationChange D/GeckoTab( 2657): Updated URL for tab with id: 1 D/GeckoTab( 2657): Updated title for tab with id: 1 E/GeckoConsole( 2657): Reader: Not parsing home page: http://digg.com/ E/GeckoConsole( 2657): [JavaScript Warning: "Error in parsing value for 'background-image'. Declaration dropped." {file: "http://digg.com/" line: 0}] [...] ----- -- Samsung Galaxy Nexus (Android 4.1.1) Nightly (10/10)
Only fx19 should be affected, since PB is only on fx19
tracking-fennec: ? → 19+
Assignee: nobody → lucasr.at.mozilla
It should be simple to disable logging while in a private tab for the Fennec-specific bits. However, the logcat above shows things that are logged on Gecko level. This makes me wonder if this bug has to be fixed on a platform level. mfinkle, what do you think?
An easy fix would be to disable the "consoleservice.enabled" pref whenever a private tab is open. That would also prevent non-private log messages from showing up when private tabs are open, but I don't think it'd be a huge problem to require users to close private tabs if they need logs. Or maybe we could even keep this pref disabled all the time (since I think we've trying to reduce logcat noise), and then devs could enable the pref when they need it?
(In reply to Brian Nicholson (:bnicholson) from comment #3) > An easy fix would be to disable the "consoleservice.enabled" pref whenever a > private tab is open. That would also prevent non-private log messages from > showing up when private tabs are open, but I don't think it'd be a huge > problem to require users to close private tabs if they need logs. Yeah, I saw that. I don't really like the idea of toggling a persistent pref for a temporary app state. However, it seems there's no runtime-only way to disable console service. So this might be the only option we have after all. > Or maybe we could even keep this pref disabled all the time (since I think > we've trying to reduce logcat noise), and then devs could enable the pref > when they need it? That would probably be a bit inconvenient for daily development i.e. having to manually enable it. One option could be to only disable it on the releases. But that would go against the recent patch to include logcat information on crash reports?
Look at bug 769298. There is a way to filter output based on private browsing state. Note that bug 769298 does not stop all output from appearing, just script errors. Also note that it only stops the output from the "Error Console", but not output sent to any other console listener. I suppose we could add an nsIScriptError dependency to nsConsoleService and filter for Android here: http://mxr.mozilla.org/mozilla-central/source/xpcom/base/nsConsoleService.cpp#179
Assignee: lucasr.at.mozilla → mark.finkle
tracking-fennec: 19+ → 20+
PB on Beta, is this happening?
If this bug gets fixed, we should also be aware of other events that appear in logcat; for example, clicking a notification for a private download shows the following: ActivityManager: START {act=org.mozilla.gecko.ACTION_ALERT_CALLBACK dat=alert:/891692741?name=download:///mnt/sdcard/Download/ubuntu-12.10-desktop-i386.iso&app=org.mozilla.fennec_brian.App&cookie= flg=0x10000000 cmp=org.mozilla.fennec_brian/.App} from pid 3696
Assignee: mark.finkle → bnicholson
tracking-fennec: 20+ → 21+
tracking-fennec: 21+ → +
filter on [mass-p5]
Priority: -- → P5
I thought we landed patches to avoid logging URLs ever. Is this still an issue?
Nope.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.