1687515 - Feature request: Clickable links in the website-provided tab-modal prompts (alert/confirm/prompt)

Status: NEW

(Toolkit :: Content Prompts, enhancement, P4)

Description

[Mike Hoye [:mhoye]]

The new notifications look great! I would like one additional thing: to be able to click links that are presented in those notifications.

This wasn't available in the previous versions of this, so there's no regression here, but it certainly would be nice to have.

Thanks.

Comment 1

[:Gijs (he/him)]

As an example usecase, google calendar uses alerts for meeting notifications, and those contain zoom/ms-teams/conferencing software links, and it would be neat if you could click on those to join the meeting!

Tentatively adding this to the tracking bug - we may consider doing this for Proton - and clarifying what we're talking about.

This is a little interesting because the content is rendered in the parent process, but the links come from the website, so we should make sure that the right principal is used when opening the link if it is clicked (to avoid potential security issues, and ensure that the right container and private browsing state is used, etc.). The XUL-based text link custom element has some infrastructure for this already (cf. https://searchfox.org/mozilla-central/rev/2c06b16a0c15ae340a0532e319cbf89ef9d21b68/toolkit/content/widgets/text.js#329 ) but not for this specific usecase - it will use the node principal or a null principal without any origin attributes. We'd probably want to add support for that code to either use a principal that we serialize into an attribute, or add an attribute with JSON to use as the origin attributes argument to the null principal creation. Either that or we'd need to add a sandboxed iframe just for the message text, which seems unfortunate and like it'll mess with layout and so on.

Orrr... we could use sandboxing for the entire iframe that we're using for the dialog as a whole. We'd need to refactor commonDialog.js a bit, as it would no longer be able to load CommonDialog.jsm . I'm also not sure if we'll run afoul of any security checks that verify that we don't load untrusted content into the parent process. So this seems like an approach that might be tricky to make work, but potentially cleaner if we do make it work.

Then there's the issue of linkification itself, as we're just given a plaintext string. To start with, only linkifying valid http/https URIs would work. In future we may want to consider linking text of the form example.tld, and other protocols, or email addresses, but those are all additional minefields...

(Adding Freddy as this intersects with some interests of his around sandboxing and frontend security...)