1989609 - New tabs in a container can't use uploaded wallpapers

Status: RESOLVED FIXED

(Firefox :: New Tab Page, defect, P1)

Description

[[:Propheticus]]

Steps to reproduce:

Right-click + New Tab (vertical tabs enabled)
Select a container, e.g. 'personal'
Click 'customise' (bottom right)
Click 'upload and image'
Select a pretty photo I made
Click 'Open'

Actual results:

Nothing changes, the background remains grey.

Expected results:

The background should've changed to my photo.
(this works in a non-container new tab)

Comment 1

[Maxx Crawford [:maxx]]

Thanks for filing. I verified this issue.

There's an extra edge case issue here as well:

1. Note whichever mode you're in (light/dark)
2. Upload a custom wallpaper that's the opposite of your current mode (dark for light, etc)
3. Expected: The color mode should dynamically update to remain visible
4. Open a tab in a Container
5. Expected: The color mode should dynamically update to remain visible
6. Actual: The color mode should is locked to the color-mode dictated by the custom uploaded image, even though it isn't visible. This makes some elements impossible to read.

Comment 2

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

The severity field is not set for this bug.
:thecount, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[Irene Ni [:ini]]

Attachment: Bug 1989609 - Create protocol handler to allow New Tabs in containers to use custom wallpapers. r=#home-newtab-reviewers

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Hi Irene,

So I started typing out my original plan and realized there was an awkward flaw with it. Here was my original plan:

Original plan that won't work

1. Instead of maintaining a single #customBackgroundObjectURL WallpaperFeed should instead iterate the existing user context IDs (you'll need to have the WallpaperFeed combine the list of public user context IDs and private ones available from these methods hanging off of ContextualIdentityService), and create a Blob URL for each of them.
2. Have WallpaperFeed send this mapping down via the store
3. Have the newtab page choose the right background image based on its userContextId

I thought the hardest part for this was getting the newtab page to learn what its userContextId (that's the numeric ID of the container) was, but the real problem is that the parent cannot create Blob URLs for non-default containers. Only a JS context inside of that container can do that - so we'd need to send the whole Blob down, and we're back at the original problem again with memory usage.

New idea that sounds scary but might not be too bad

We'd create a new protocol, like moz-newtab-background:// that is usable from the privileged about content process, and would directly stream the bytes from the file in the profile. I realize that sounds scary, but I can probably mentor you through it.

Less complicated, but maybe not forward-thinking (and we'd want Gijs' input on this)

We'd register a new resource protocol substitution, mapping something like resource://newtab-background/ to the profile's wallpaper folder, and make this accessible from the privileged about content process. This one worries me, because I don't actually know that we have the flags in place to let us restrict that to just the privileged about content process, and I'd hate to accidentally expose the profile directory to the web at large (even if the UUID for the background is basically impossible to guess). I also know that resource:// isn't something we're aiming on investing in in the short term.

So my preference is the second solution, but it's not going to be a quick fix. This is going to be several days of work, probably. Do you have time for it?

Comment 5

[Mike Conley (:mconley) (:⚙️)]

So I spoke to some folks from the DOM team, and ultimately, we think that the Blob URL solution isn't going to work out in the long-term due to how containers segment access to Blob URLs. We're going to go with a custom protocol handler. This is going to be a little tricky, but the good news is that there are pre-existing examples to work off of, like the PageThumbsProtocolHandler and the PageIconProtocolHandler.

---

Step 1: Create Stubbed Protocol Handler

We need to create a C++ protocol handler for moz-newtab-wallpaper:// URLs. Start by creating a minimal, compilable stub that returns errors for all methods. Once this builds, we'll implement the actual functionality.

Create the files:

browser/components/newtab/MozNewTabWallpaperProtocolHandler.h

• Declare a new class, MozNewTabWallpaperProtocolHandler.
• We'll probably want the same includes as PageThumbProtocolHandler
• Lets use the mozilla::newtab namespace rather than mozilla::net
• Inherit from SubstitutingProtocolHandler (see netwerk/protocol/res/PageThumbProtocolHandler.h as reference)
• Implement nsISubstitutingProtocolHandler and nsSupportsWeakReference
• Declare static GetSingleton() method
• Declare NewStream() returning RefPtr<RemoteStreamPromise> (for IPC support)
• Declare ResolveSpecialCases() override (will map URIs to file paths)
• Declare SubstituteChannel() override (will create channels)
• Use a private constructor/destructor
• Use a static StaticRefPtr<MozNewTabWallpaperProtocolHandler> sSingleton;

browser/components/newtab/MozNewTabWallpaperProtocolHandler.cpp

• Include MozNewTabWallpaperProtocolHandler.h
• Define #define NEWTAB_WALLPAPER_SCHEME "moz-newtab-wallpaper"
• Implement singleton pattern with ClearOnShutdown() (see example)
• Constructor: MozNewTabWallpaperProtocolHandler() : SubstitutingProtocolHandler(NEWTAB_WALLPAPER_SCHEME) {}
• Add NS_IMPL macros (see PageThumbProtocolHandler.cpp lines 56-60)
• Stub implementations:
  • NewStream(): return RemoteStreamPromise::CreateAndReject(NS_ERROR_NOT_IMPLEMENTED, func);
  • ResolveSpecialCases(): return false;
  • SubstituteChannel(): return NS_ERROR_NOT_IMPLEMENTED;

browser/components/newtab/moz.build:

...

EXPORTS.mozilla.newtab += [
    "MozNewTabWallpaperProtocolHandler.h",
]

UNIFIED_SOURCES += [
    "MozNewTabWallpaperProtocolHandler.cpp",
]

In browser/components/newtab/components.conf, register your new protocol class. You'll need to generate a new uuid to put in the cid field - use uuidgen to do that.

Classes = [
...
    {
        'cid': '{GENERATED-UUID-HERE}',
        'contract_ids': ['@mozilla.org/network/protocol;1?name=moz-newtab-wallpaper'],
        'singleton': True,
        'type': 'mozilla::newtab::MozNewTabWallpaperProtocolHandler',
        'headers': ['/browser/components/newtab/MozNewTabWallpaperProtocolHandler.h'],
        'constructor': 'mozilla::newtab::MozNewTabWallpaperProtocolHandler::GetSingleton',
        'protocol_config': {
            'scheme': 'moz-newtab-wallpaper',
            'flags': [
                'URI_STD',
                'URI_IS_UI_RESOURCE',
                'URI_IS_LOCAL_RESOURCE',
                'URI_NORELATIVE',
                'URI_NOAUTH',
            ],
            'default_port': -1,
        },
    },
]

Build and verify with ./mach build and see if ./mach run works.

Let's see if we can get that far, and what blocks us, and then we'll move on to the next step, which would be to implement the protocol in the parent process so that we can use moz-newtab-wallpaper from the URL bar and have it show a wallpaper in the content area. The next step would then be to remote the protocol so that it can work in the privileged about content process. The final step will be to update the WallpaperFeed.sys.mjs to use that new protocol for the URL it sends down to the newtab.

Comment 6

[Irene Ni [:ini]]

Thank you so much for this detailed writeup! I can get started on the steps listed out so far - having the examples is really helpful. I'll let you know if I run into any roadblocks.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/d2fb41d9d1fc
https://hg.mozilla.org/integration/autoland/rev/ed444fe4d769
Create protocol handler to allow New Tabs in containers to use custom wallpapers. r=home-newtab-reviewers,necko-reviewers,mconley,kershaw,ckerschb

Comment 9

[Sandor Molnar[:smolnar]]

Backed out for causing build bustages @ NeckoParent.cpp

Backout link: https://hg.mozilla.org/integration/autoland/rev/7f39ffc1915827302b0c4825a4d9ba065b9b7c44

Push with failures

Failure log -> ERROR - /builds/worker/checkouts/gecko/netwerk/ipc/NeckoParent.cpp(940,7): error: use of undeclared identifier 'NullPrincipal'

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/b6b13a99af4d
https://hg.mozilla.org/integration/autoland/rev/b8b36cfd12b3
Create protocol handler to allow New Tabs in containers to use custom wallpapers. r=home-newtab-reviewers,necko-reviewers,mconley,kershaw,ckerschb

Comment 11

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/b8b36cfd12b3