1708612 - Tracking protection icon is hidden on about:blank and about:newtab, but not on custom new tab/home pages

Status: NEW

(Firefox :: Protections UI, defect, P3)

Description

[Shane Hughes [:aminomancer]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

• Open a new tab to the default new tab page. (or type about:newtab into urlbar)
• The tracking protection icon is hidden, because the about: URL has isContentPrincipal = false
• Install an extension that overrides the new tab page, go to some webpage where the tracking protection is visible, (so a webpage or an extension page) and try opening a new tab.

Actual results:

• The tracking protection icon briefly disappears when the tab is created, (I assume the URL is about:blank in that moment) then reappears when the URL becomes moz-extension://... and ContentBlockingAllowList.canHandle is called on it.
• So basically the icon stutters every time a new tab is opened unless the user sticks to the default, built-in new tab page.

Expected results:

To be fair, the tracking protection icon is not useless on custom new tab pages. So I understand why it's not hidden. Clicking it will open the popup and the options and information in there will be valid. The same can't be said for the built-in new tab page. But the constant stuttering when opening a new tab is a much more serious issue, which might discourage a lot of users from installing NTP extensions.

I made a temporary solution for myself which is easy enough to implement. Simply change gProtectionsHandler.onLocationChange so that, in addition to checking the principal, it also checks if the selected browser's URL matches the user's home page or new tab page URL.

That isn't a perfect solution though, because it hides the tracking protection icon under a condition where the tracking protection icon could actually be meaningfully interacted with. I've never had any cause to change the tracking protection settings on an extension page before, let alone a simple new tab/home page, but I'm sure there are edge cases where this would be an undesirable behavior.

So maybe there's another solution that someone with more knowledge than me can pull off. For example, it seems practical to stop the tracking protection icon from being hidden until content has loaded. That way it would still be visible on custom new tab pages, and would still be hidden on system pages, but it would be visible during those milliseconds when content is first loading in a browser. Just make it uninteractive but visible until there's more information about the content. Removes the icon flickering without removing the button itself.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::New Tab Page' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Alex Cornestean]

Hello,

I’m not sure I’ve reproduced the issue as I did not exactly understand from the bug report how the tracking protection icon should behave when opening a new tab while an add-on overriding the new tab page is installed.

When opening a new tab (with an add-on overriding the new tab page being installed), the icon does appear to flash. For more details, see the attached videos. One is from the latest Beta and the second one from the latest Release. I did not attach a video from Nightly as it behaves exactly like Beta.

Note that I’ve tested the latest Nightly (90.0a1/20210509213623), Beta (89.0b10/20210509185840) and Release (88.0.1/20210504152106) under Windows 10 x64 and Ubuntu 16.04 LTS with Tabliss and New Tab Override add-ons.

Please let me know if the behavior shown in the videos matches what you’ve observed and I’ll update the status of the issue accordingly. Thank you !

Comment 3

[Alex Cornestean]

Attachment: 2021-05-10_14h14_40.mp4

Comment 4

[Alex Cornestean]

Attachment: 2021-05-10_14h19_04.mp4

Comment 5

[Shane Hughes [:aminomancer]]

Maybe I'm misunderstanding, or maybe it's just happening so fast you can't see it. Both your videos clearly show the tracking icon disappearing and then reappearing. If you look at it frame by frame you can see that the spot where the tracking icon goes is briefly occupied by the identity icon instead, which uses the insecure icon. (lock with a red strike through it) Then the tracking icon reappears, sliding over the identity icon, when the page has loaded further.

The showing/hiding of the icon is prompted by a location change event. However, it decides whether to show/hide by checking if it's a content or system principal, and the logic behind that is in binary functions, outside my narrow band of knowledge. But I know about:blank and about:newtab are both system pages, whereas extension pages pass that test for a content principal.

If you type about:blank in your urlbar you can also clearly see that there's no tracking icon. So even if you couldn't see it in the video, you can still confirm it's happening by the fact that the tabbed browser starts on about:blank, a system page, and the icon doesn't appear on system pages.

Of course a user-installed extension's page shouldn't qualify as system content in any circumstance, nor can about:blank be changed. So the only reasonable solutions would involve changing the callback. My fix just has it checking not only the principal but also whether the location matches the user's home page or new tab page. It could also be controlled independently by some class method in the tabbrowser component, so that the icon is forced hidden when opening a new tab or window or clicking the "home" button. That way it wouldn't be confusingly hidden if the user had their home page set to something on the web like mozilla.com, then manually typed in that address.

But there might be a workaround to avoid having to hide the tracking protection icon altogether. One idea is just deferring the location change callback, since the flicker happens so quickly. If it simply waited for a 1-5 millisecond timeout before calling ContentBlockingAllowList.canHandle, that might eliminate the flicker without hiding the TP icon. That seems a little sloppy though, since the actual time between about:blank and the final new tab page is not constant. So maybe it shouldn't hide the tracking protection icon on about:blank in the first place, until navigation has finished or something. Not sure yet if that's actually feasible so I didn't mention it before.

Personally, even if the flicker is fixed, I'll keep using my modified callback to hide the icon on my new tab page, since my new tab and home pages are not web content and, on the outside, look pretty much like the built-in new tab page or any other system page anyway. But I doubt very many other users will go to the same lengths I did, or will feel safe overriding source code.

Comment 6

[Alex Cornestean]

Hello and thank you for the additional info !

I’ve checked the videos frame by frame and the issue is there as described in Comment 5.

Comment 7

[Scott [:thecount] Downe]

I'm taking a guess that this might belong in another component.

Comment 8

[Shane Hughes [:aminomancer]]

(In reply to Scott [:thecount] Downe from comment #7)

I'm taking a guess that this might belong in another component.

Thanks — I'm not sure which component browser-siteProtections.js falls under, but that's probably the file that should be edited to fix this issue, since it contains gProtectionsHandler, which has the location change listener that hides the tracking protection icon

Comment 9

[Jared Wein [:jaws] (please needinfo? me)]

I think ideally if it is already visible and the user opens a new tab and has a custom NTP set, then we shouldn't hide it temporarily. I wouldn't want to hide this on custom NTP just because as comment #0 says there is value there for custom new tab pages.

Comment 10

[Paul Zühlcke [:pbz]]

Thanks for filing the bug! I think it comes down to whether addon pages can contain tracking content or have Total Cookie Protection enabled, which means users need to be able to configure these features. If addons can override that anyway there is no need to show the UI, otherwise we should keep it.