Feature request: a WebExtension API to change the window title

RESOLVED FIXED in Firefox 56

Status

()

Toolkit
WebExtensions: General
P3
normal
RESOLVED FIXED
7 months ago
6 days ago

People

(Reporter: hmijail+persona, Assigned: bsilverberg)

Tracking

(Blocks: 2 bugs, {dev-doc-complete})

unspecified
mozilla56
dev-doc-complete
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox56 fixed)

Details

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

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Reporter)

Description

7 months ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170118123726

Steps to reproduce:

Existing Firefox add-ons like FireTitle (https://addons.mozilla.org/en-US/firefox/addon/firetitle/) which change the title of the existing browser window don't seem to have a way to be implemented with WebExtensions.

In case of security concerns, note that it might be enough to blindly add a prefix to the title, instead of reading it and/or fully replacing it.

Updated

7 months ago
Whiteboard: [design-decision-needed]

Comment 1

7 months ago
More specifically, this add-on is able to display Firefox windows' title given a pattern:
If %t stands for the window's current tab title, %m for the browser's name, and %n the user-customized name of the window, "%n - %t - %m" would set the window's title to "My Dev Window - 1333375 Feature request: … - Mozilla Firefox"

Other kind of %X tokens such as tab-group name, age of the window, are available, and there are user requests for yet new ones.
"%t10" truncate the tab title to its first 10 characters.
Until now, it worked as follow: on document's title change, a signal was catched, updating window's title according to the user-defined pattern.


There are several valid uses for titlebar renaming, for example:
- Thematic windows ("Dev", "Work", "Entertainment", "NSFW")
- Hide tab's title
- Automatic placement of a window given its title

Cons:
- Security risks for this API seems to be fairly minimal (the brand name could be set un-removable if it is a concern)
- Branding impact are minimal too since titlebar isn't managed by Firefox but by the window's manager.

Comment 2

6 months ago
Similarly to bug 1333943 we aren't quite sure why we should do this when the window title is essentially the tab title. There were comments that this was quite hard to implement properly, which given the benefit doesn't seem worth it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → WONTFIX
Whiteboard: [design-decision-needed] → [design-decision-denied]

Comment 3

6 months ago
But the point of the feature request is that having a window title independent of the tabs in the window would be useful. 

For example : window "API docs", window "shopping". A tab named "amazon" could exist in both, and you couldn't know from that name what window choose in some window list. But if you can set the window title, you can know what the window is about.

Comment 4

6 months ago
Imagine you have a tab in a tabgroup in a browser's window.

What should the title of the window be? The browser's name ? The tab page title ? The tabgroup name ? A mix of all of the above ? Even more than that ?

Allowing the user (through an extension or via the browser's settings, e.g. in about:config) to decide what should be displayed *is* a useful feature, there is a user base for that, and it would be a shame to drop support for it just because it's not easy to find an elegant implementation.

Comment 5

6 months ago
Firefox has always been highly customizable, this means close to any user's needs, as opposed to chrom(ium) which is close to most users needs.

If you go the "most users" way, then, you'll lose the "geeks" support. They might be a negligible 5% user base, but they surely are the most influential part. If they get angry about how their needs/habits are taken care of, they'll (rightfully) leave.

If support for the extensions I use or maintain is dropped, I'll get angry with Firefox. Especially if the given argument is "Duh, I don't use this feature and it's a pain to implement."
Comment hidden (advocacy)

Comment 7

6 months ago
This is somewhat possible by injecting a content script into every website that changes window.title. The only limitation is that the window title will still have the "- Firefox" suffix.

Comment 8

5 months ago
(In reply to Andy McKay [:andym] from comment #2)
> we aren't quite sure why we should do this when the
> window title is essentially the tab title.

Andy, I've used FireTitle for more than 10 years because I always have multiple Firefox windows open with each window being devoted to a separate project. I've yet to find a better solution for managing dozens of browser tabs per project than this: 1) multiple Firefox windows, 2) the FireTitle extension, 3) the Tree Style Tab extension, and 4) a window switcher (e.g., Openbox) that shows a vertical list of all application windows with the full title of each window.

Without the ability to change the title of Firefox windows, I won't know which Firefox window to switch to; the selected tab in each window will rarely identify the project to which a Firefox window is devoted. Not knowing which Firefox window to switch to will be excruciating because I switch windows hundreds of times per day.

Is there a way for a user to make a donation to Mozilla to sponsor a feature? I would donate hundreds of dollars to ensure that I don't lose the ability to set Firefox window titles.
Flags: needinfo?(amckay)
(Reporter)

Comment 9

5 months ago
Count me in for feature sponsoring too! As David, without FireTitle I'm mostly limited to a single-window-Firefox, and that will eventually make me check other browsers. I'd prefer to stay with Firefox.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 10

5 months ago
(sorry, looks like I changed the status to VERIFIED by mistake, even though I tried to cancel it by reloading the page before saving the changes)

Comment 11

5 months ago
Firetitle is still possible, the only limitation is that the selected tab will also contain the modified window title. I think that's a trade-off OK to have.

Updated

5 months ago
Flags: needinfo?(amckay)

Comment 12

5 months ago
No it's not!

Changing a document's title can interfere with a page behavior. A page's javascript can check whether the document's title has been changed or not.

FireTitle was read-only over the DOM. That's a good security feature. That's what most extensions should do. And now the extension should pollute every single webpage with javascript? How can this be a solution? Is there something I'm missing here?

Comment 13

5 months ago
Saddly I have the impression that everything is done to kill the features of firefox. Nothing is ready for the switch, the webextensions planned for version 57 will be lower than Chrome!

I am a FireTitle user. I am a Tabs groups user ... But is the user still important?
I wanted to make the unsplash extension that exists for 6 months in Chrome, I have to wait for June, maybe ...

Comment 14

5 months ago
This is very disappointing. Without this feature there is no way to properly indicate what Firefox profile is being used.
(In reply to hmijail+persona from comment #10)
> (sorry, looks like I changed the status to VERIFIED by mistake, even though
> I tried to cancel it by reloading the page before saving the changes)

VERIFIED was set by mistake, let's go back to RESOLVED. If some WebExtensions developer wants to set it back to VERIFIED, well, :-( go ahead.
Status: VERIFIED → RESOLVED
Last Resolved: 6 months ago4 months ago

Comment 16

4 months ago
(In reply to Tim Nguyen :ntim from comment #7)
> This is somewhat possible by injecting a content script into every website
> that changes window.title.

Is this solution compatible with all the single-page apps that change document.title without loading new pages?

Comment 17

4 months ago
(In reply to Andy McKay [:andym] from comment #2)
> the window title is essentially the tab title.

Does anyone know if the WebExtensions API might support an extension that allows the user to mark a tab (i.e., like pinning) in such a way that the window title would include the title of the marked tab instead of the selected tab? This would give the user some control over how windows are titled.

Comment 18

4 months ago
There's been quite a bit of chatter about this one and I've been convinced that the ability to change the window title has some useful OS integration benefits. Being able to switch to Firefox windows and see that information in other processes is kind of neat. 

From an evaluation point of view such an API doesn't have any major UX, security or performance concerns that we know of. The comment in the meeting that this might be tricky to implement still holds.

That's a kind of arbitrary reversal of what we said in the design-decision meeting, I'll add a note for the next meeting so I can explain why in that meeting. For those raring to go, it might be best to hold off patches until I've explained why I think this is useful. 

After that meeting, the next steps are to figure out an API. There was a question if we should just allow complete changes - or just additions. For most of the use cases here the ability to just add to the title a prefix or suffix would be sufficient I believe.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
Whiteboard: [design-decision-denied] → [design-decision-approved]

Comment 19

4 months ago
(In reply to Andy McKay [:andym] from comment #18)
> After that meeting, the next steps are to figure out an API. There was a
> question if we should just allow complete changes - or just additions. For
> most of the use cases here the ability to just add to the title a prefix or
> suffix would be sufficient I believe.

I think we can simply add support for a new "title"/"title-prefix" field in the following methods:
- windows.create()
- windows.update()
- windows.get*()

There shouldn't really be new API methods for this since create/update/get* are supposed to do the job.

Updated

4 months ago
Priority: -- → P3
Whiteboard: [design-decision-approved] → [design-decision-approved][triaged]

Updated

2 months ago
Blocks: 1215059
(Assignee)

Updated

a month ago
Assignee: nobody → bob.silverberg
Comment hidden (mozreview-request)

Comment 21

a month ago
mozreview-review
Comment on attachment 8886238 [details]
Bug 1333376 - Support reading the title and setting the title preface of a Window object,

https://reviewboard.mozilla.org/r/157020/#review162114

::: commit-message-03bcd:1
(Diff revision 1)
> +Bug 1333376 - Feature request: a WebExtension API to change the window title, r?aswan

Please update the subject here, at the least it shouldn't include "Feature Request"

::: browser/components/extensions/ext-utils.js:634
(Diff revision 1)
>  
> +  get title() {
> +    return this.window.document.title;
> +  }
> +
> +  addPrefaceToTitle(titlePreface) {

nit: this should just be something like "setTitlePreface" to be more clear about what it does

::: browser/components/extensions/test/browser/browser_ext_windows.js:77
(Diff revision 1)
> +
> +  async function createApiWin(options) {
> +    extension.sendMessage("create", options);
> +    let apiWin = await extension.awaitMessage("created");
> +    let realWin = windowTracker.getWindow(apiWin.id);
> +    await awaitUrlLoaded(realWin, START_URL);

this calls `loadURI()` which means you're never actually testing that the title is set correctly for the initial load.
Attachment #8886238 - Flags: review?(aswan) → review+
Comment hidden (mozreview-request)
(Assignee)

Comment 23

a month ago
mozreview-review-reply
Comment on attachment 8886238 [details]
Bug 1333376 - Support reading the title and setting the title preface of a Window object,

https://reviewboard.mozilla.org/r/157020/#review162114

> this calls `loadURI()` which means you're never actually testing that the title is set correctly for the initial load.

That is correct. The issue I faced was that, after calling windows.create(), the title is not available until the document finishes loading in the window. I needed to incorporate some sort of wait into the test somewhere, and couldn't seem to get anything working in the background script itself. This `awaitUrlLoaded` method gives me the wait I need, but yes, it does mean that I am not checking the title after the initial load. 

The assumption I am making is that if the title preface is still correct after loading the url into the window again, then the title preface was correct *before* doing that load as well. Perhaps this is not a safe assumption to be making.

Can you suggest a way for me to wait for the document to finish loading as part of the initial call to windows.create()? I tried something similar to what is being done in browser_ext_windows_create_url.js [1], but that seems very convoluted and also still didn't seem to wait long enough for the title to resolve properly.

[1] http://searchfox.org/mozilla-central/rev/cef8389c687203085dc6b52de2fbd0260d7495bf/browser/components/extensions/test/browser/browser_ext_windows_create_url.js#15-59

Comment 24

a month ago
mozreview-review-reply
Comment on attachment 8886238 [details]
Bug 1333376 - Support reading the title and setting the title preface of a Window object,

https://reviewboard.mozilla.org/r/157020/#review162114

> That is correct. The issue I faced was that, after calling windows.create(), the title is not available until the document finishes loading in the window. I needed to incorporate some sort of wait into the test somewhere, and couldn't seem to get anything working in the background script itself. This `awaitUrlLoaded` method gives me the wait I need, but yes, it does mean that I am not checking the title after the initial load. 
> 
> The assumption I am making is that if the title preface is still correct after loading the url into the window again, then the title preface was correct *before* doing that load as well. Perhaps this is not a safe assumption to be making.
> 
> Can you suggest a way for me to wait for the document to finish loading as part of the initial call to windows.create()? I tried something similar to what is being done in browser_ext_windows_create_url.js [1], but that seems very convoluted and also still didn't seem to wait long enough for the title to resolve properly.
> 
> [1] http://searchfox.org/mozilla-central/rev/cef8389c687203085dc6b52de2fbd0260d7495bf/browser/components/extensions/test/browser/browser_ext_windows_create_url.js#15-59

`BrowserTestUtils.waitForNewWindow()` with `intitialBrowserLoaded` set to true?
Comment hidden (mozreview-request)
(Assignee)

Comment 26

a month ago
mozreview-review-reply
Comment on attachment 8886238 [details]
Bug 1333376 - Support reading the title and setting the title preface of a Window object,

https://reviewboard.mozilla.org/r/157020/#review162114

> `BrowserTestUtils.waitForNewWindow()` with `intitialBrowserLoaded` set to true?

Nice. Thanks. :)
(Assignee)

Comment 27

a month ago
My test doesn't seem to pass on Linux or Windows (I only tested locally on OS X), I think because the logic for what makes up the page title is different on those platforms. I need to revisit the test.
(Assignee)

Updated

a month ago
Component: WebExtensions: Untriaged → WebExtensions: General
Comment hidden (mozreview-request)

Comment 29

a month ago
Pushed by bsilverberg@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/80d83599863a
Support reading the title and setting the title preface of a Window object, r=aswan

Comment 30

a month ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/80d83599863a
Status: REOPENED → RESOLVED
Last Resolved: 4 months agoa month ago
status-firefox56: --- → fixed
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla56

Updated

a month ago
Keywords: dev-doc-needed

Comment 31

17 days ago
Noted that this won't work on pages like about:blank. For example, fire up windows-manipulator from mdn examples with titlePreface added with web-ext. Then fire windows.update and the title is not changed. Navigate to http or https page and the change shows up. Is that something we should file a bug for or document?
(Assignee)

Comment 32

17 days ago
(In reply to Andy McKay [:andym] from comment #31)
> Noted that this won't work on pages like about:blank. For example, fire up
> windows-manipulator from mdn examples with titlePreface added with web-ext.
> Then fire windows.update and the title is not changed. Navigate to http or
> https page and the change shows up. Is that something we should file a bug
> for or document?

I can not reproduce this, not on OS X anyway. Maybe I'm misunderstanding the STR, but I've tried calling windows.update on a window containing just about:blank, and it does add the title preface, immediately. It also works with windows.create with about:blank.
Flags: needinfo?(amckay)

Comment 33

16 days ago
Ah I was testing on Windows. I'll see if I can reproduce on OS X.
(Assignee)

Comment 34

15 days ago
I just tested on Windows as well and found that about:blank and about:config, which have no title, don't get prefaced on Windows, but about: pages that do have a title, such as about:preferences, do get prefaced. All pages seem to get prefaced on OS X. This seems like it must have to do with the underlying implementation of window titling in the OS's and not something our code has anything to do with. I could dig a bit more into the code that implements the window titling, but I'm inclined to say we just document this at this point.

Comment 35

15 days ago
Cool thanks, we've got dev-doc-needed so I'm sure wbamberg will read this. Let's spin off a new low priority bug we can bounce down to the Firefox team.
Flags: needinfo?(amckay)
I've updated:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/windows/Window
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/windows/create
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/windows/update

Let me know if this covers it.
Flags: needinfo?(bob.silverberg)
I just made the title bar customizable with my Nightly Tester Tools port: https://github.com/kyoshino/nightlyttr

One thing: the title won't be reset when titlePreface is empty. Will file a bug for that.
(Assignee)

Updated

15 days ago
Blocks: 1387425
(Assignee)

Comment 38

15 days ago
(In reply to Andy McKay [:andym] from comment #35)
> Cool thanks, we've got dev-doc-needed so I'm sure wbamberg will read this.
> Let's spin off a new low priority bug we can bounce down to the Firefox team.

I've opened bug 1387425 as a spin-off.
Flags: needinfo?(bob.silverberg)
(Assignee)

Comment 39

15 days ago
(In reply to Will Bamberg [:wbamberg] from comment #36)
> I've updated:
> https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/windows/Window
> https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/windows/create
> https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/windows/update
> 
> Let me know if this covers it.

Looks good, Will. Thanks for taking care of this. One wrinkle in the caveat: Luca did some testing and it looks like on Linux, if you try to use the titlePreface feature on a window without a title it doesn't work initially, but if you reload the window it starts working, which is different from the behaviour on both OS X and Windows. I'm not sure if we need to document that as well or not.
Thanks Bob. Since this seems very OS-specific and a niche case, I've made the docs a little vaguer:

"Depending on the underlying operating system, this might not work on browser windows that don't have a title (such as about:blank in Firefox)."
Keywords: dev-doc-needed → dev-doc-complete
You need to log in before you can comment on or make changes to this bug.