WebExtension popups include the page URL in the window title

NEW
Unassigned

Status

P2
normal
2 years ago
11 days ago

People

(Reporter: oleary.gabe, Unassigned)

Tracking

48 Branch
x86_64
Windows 10

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [design-decision-approved]triaged)

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

Steps to reproduce:

When I create a window with a local extension page the title of the window shows the url, and then the page title.
chrome.windows.create({ url: chrome.extension.getURL('compare.html'), type: "popup", state: 'maximized' });

compare.html include:
<html>
<head>
<title>Compare</title>
...
</head>
...
</html>



Actual results:

Visible title of window is : 'moz-extension://extension-id - Compare'


Expected results:

The expected behavior from chrome is for window only display the page title, and not the url preceding: 'Compare'
(Reporter)

Updated

2 years ago
Component: Untriaged → WebExtensions
OS: Unspecified → Windows 10
Product: Firefox → Toolkit
Hardware: Unspecified → x86_64

Updated

2 years ago
Summary: WebExtensions Title of page includes page url (ugly) → WebExtension popups include the page URL in the window title

Updated

2 years ago
Status: UNCONFIRMED → NEW
Component: WebExtensions → WebExtensions: Frontend
Ever confirmed: true
Whiteboard: [design-decision-needed]

Updated

2 years ago
Priority: -- → P5
Whiteboard: [design-decision-needed] → [design-decision-needed]triaged

Updated

2 years ago
Duplicate of this bug: 1305032
To be discussed at Dec. 13, 2016 WE triage meeting. 

Agenda: https://docs.google.com/document/d/1S1QrBK1hrulE7dlLiQzjMupHUUSwDYRYAOXiqtMHe-k/edit#

Comment 3

2 years ago
We've been trying to make it clear that when something happens, the reason for it is clear to the end user. The ability to create a popup with no URL bar means that there could be absolutely no info to the user. 

In bug 1266012 we show the add-on in the URL bar and in bug 1318144 we show the add-on in the ID. I think we should continue the trend and the page title should contain Extension: [Extension name] - Page title. Much nicer than showing moz-extension and more informative to the end user.

Just pinging dveditz to check that sounds right.
Flags: needinfo?(dveditz)
The main thing we're trying to accomplish with the URL bar for web page popups is to prevent spoofing/phishing by showing exactly where the content originated from. The URL for a web extension doesn't convey much to a user except "this is an extension" so we don't need to show that as long as the popup can't be confused with one from a web page. Your proposal sounds like it does that. If it's not explicitly window.open() it doesn't even really need a URL bar; a panel with some title text would do (plus the "Extension:" prefix), which seems to be what this bug is asking for.

bug 1318144 is not right; bug 1318114 is maybe what you meant?
Flags: needinfo?(dveditz)

Comment 5

2 years ago
> bug 1318144 is not right; bug 1318114 is maybe what you meant?

Thanks for the correction and clarity. Sounds like we are good to go with this.

Updated

2 years ago
Whiteboard: [design-decision-needed]triaged → [design-decision-approved]triaged

Comment 6

9 months ago
Worse than the aboce, I am using

browser.windows.create(
  {titlePreface: "New bookmark",
   type: "popup",
   url: url,
   height: 150,
   width: 375,
   left: 300,
   top: 300,
   allowScriptsToClose: true
  }
)

in my extension to create a "popup", and the title piece is totally ignored, I get a resulting window with:

"moz-extension://.... - Mozilla Firefox"

as title, which is not only unreadable and unfriendly for common human beings, but non meaningful :-(

I am assuming this can be corrected / improved as part of this bug, so adding it here rather than opening a new bug.
Let me know if you prefer I open a new one. Thank you.

Comment 7

8 months ago
The usability of popups and windows from extensions is still marginal. Comment 3 will certainly improve the situation, but I'm wondering if there is more we can do. Asking for some UX input on this one. Is there a way to display the title in a user-friendly way, but still inform the user that the window comes from an extension?
Flags: needinfo?(emanuela)

Comment 8

8 months ago
Created attachment 8966257 [details]
Popup Window Extension

Simple extension that adds a toolbar button that, when clicked, will create a small and maximized popup window with the title "Page Title". Works on Firefox and Chrome.

Comment 9

8 months ago
Created attachment 8966258 [details]
Chrome Popup

Example of an extension popup created in Chrome. Note that it only displays the window title (no indication of the source of the popup).

Comment 10

8 months ago
Created attachment 8966260 [details]
Firefox Popup

Example of an extension popup in Firefox. Note the title bar shows it is from an extension, but it isn't very meaningful. This bug would clean it up a bit, adding the "Extension" prefix followed by the name of the extension, followed by the actualy HTML title. But is that going to be too long to fit onto smaller popups?

Updated

7 months ago
Priority: P5 → P2
Created attachment 8970936 [details] [diff] [review]
Display extension name in title instead of moz-extension URL

My new employer, Privowny, hits this bug and the title of our WebExtension popups becomes so ugly our users and testers complain. I would like to propose a change here, for which I have a fix in hands: display the name of the extension instead of its moz-extension URL. It's a compromise between the current situation (strong) and no prefix at all for the title (weak). I am attaching this patch now.
Attachment #8970936 - Flags: review?(mixedpuppy)
Created attachment 8970941 [details] [diff] [review]
v2 of my patch

Sorry, attached the wrong version. This one, with non-emptyness test on extension.name is better.
Attachment #8970936 - Attachment is obsolete: true
Attachment #8970936 - Flags: review?(mixedpuppy)
Attachment #8970941 - Flags: review?(mixedpuppy)
hi dveditz, any opinion about the compromise (and corresponding fix) I proposed above?
see comment 13
Flags: needinfo?(dveditz)
IMO when its in a tab, I see no reason to have the extension name included in the title.  The security dropdown should say what it is.  We should also somehow cover the window titles, attachment 8970941 [details] [diff] [review] doesn't handle that (see xpi that mconca attached).
Shane: as far as I can tell that's how tabs behave currently: the site into box says "Extension (<name>)" next to the ugly moz-extension URL in the address field but the Title is entirely specified by the extension and contains no ugly bits. Daniel's patch is only in the case when the location bar is hidden. Although it's in a file called tabbrowser.js we wouldn't really call them "tabs".

Daniel: My preference would be for Andy's comment 3 ("Extension: [<name>]" as a prefix, though probably better to match the site identity box for consistency and l10n reuse: "Extension (<name>)"). Since Web Extensions are not necessarily reviewed this is a slight bit of protection against a rogue extension trying to spoof browser UI. Then again a name that was spoofy in some panel context would probably look pretty odd on the installation prompt to start with. If we can get buy-in from other security folks I could live with your patch as-is.
Flags: needinfo?(dveditz) → needinfo?(ptheriault)
> If we can get buy-in from other security folks I could live
> with your patch as-is.

You logic sounds fine to me - Extension <name> seems like a decent compromise.
Flags: needinfo?(ptheriault)
(In reply to Daniel Veditz [:dveditz] from comment #16)

> Daniel: My preference would be for Andy's comment 3 ("Extension: [<name>]"
> as a prefix, though probably better to match the site identity box for
> consistency and l10n reuse: "Extension (<name>)"). Since Web Extensions are
> not necessarily reviewed this is a slight bit of protection against a rogue
> extension trying to spoof browser UI. Then again a name that was spoofy in
> some panel context would probably look pretty odd on the installation prompt
> to start with. If we can get buy-in from other security folks I could live
> with your patch as-is.

Thanks! I can of course rather tweak the patch to add that localized "Extension (*)" string. Let me know if I should spend two cycles on that?
Comment on attachment 8970941 [details] [diff] [review]
v2 of my patch

>diff --git a/browser/base/content/tabbrowser.js b/browser/base/content/tabbrowser.js
>index 784986177f05..e100880907cb 100644
>--- a/browser/base/content/tabbrowser.js
>+++ b/browser/base/content/tabbrowser.js
>@@ -887,6 +887,18 @@ window._gBrowser = {
>           aBrowser.currentURI);
>         if (uri.scheme == "about")
>           newTitle = uri.spec + sep + newTitle;
>+        else if (uri.scheme == "moz-extension") {
>+          // in the case of a WebExtension, we display its official name instead
>+          // the URL
>+          let mozExtensionHostname = uri.host;
>+          for (let extension of WebExtensionPolicy.getActiveExtensions()) {
>+            if (extension.mozExtensionHostname == mozExtensionHostname &&
>+                extension.name)
>+              return extension.name + sep + newTitle;
>+          }

Shouldn't need to loop...

          let extension = WebExtensionPolicy.getByHostname(uri.host);
          return `Extension (${extension.name})${sep}${newTitle}`;

Assuming some l10n will happen, so will wait for that.
Attachment #8970941 - Flags: review?(mixedpuppy)

Updated

5 months ago
Product: Toolkit → WebExtensions

Updated

3 months ago
Flags: needinfo?(emanuela)
Comment hidden (advocacy)
You need to log in before you can comment on or make changes to this bug.