Closed Bug 1333376 Opened 7 years ago Closed 7 years ago

Feature request: a WebExtension API to change the window title

Categories

(WebExtensions :: General, defect, P3)

Product:
WebExtensions
Component:
General
Type:
defect

Tracking

(firefox56 fixed)

Status:
RESOLVED FIXED
Milestone:
mozilla56
Tracking Flags:
Tracking Status
firefox56 --- fixed

People

(Reporter: hmijail+persona, Assigned: bsilverberg)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-complete, Whiteboard: [design-decision-approved][triaged])

Attachments

(1 file)

Bug 1333376 - Support reading the title and setting the title preface of a Window object,
59 bytes, text/x-review-board-request
aswan
: review+
Details 
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.
Whiteboard: [design-decision-needed]
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.
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
Closed: 7 years ago
Resolution: --- → WONTFIX
Whiteboard: [design-decision-needed] → [design-decision-denied]
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.
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.
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."
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.
(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)
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
(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)
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.
Flags: needinfo?(amckay)
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?
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 ...
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
Closed: 7 years ago → 7 years 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?
(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.
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]
(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.
Priority: -- → P3
Whiteboard: [design-decision-approved] → [design-decision-approved][triaged]
Assignee: nobody → bob.silverberg
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 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 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 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. :)
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.
Component: WebExtensions: Untriaged → WebExtensions: General
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
https://hg.mozilla.org/mozilla-central/rev/80d83599863a
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
status-firefox56: --- → fixed
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Keywords: dev-doc-needed
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?
(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)
Ah I was testing on Windows. I'll see if I can reproduce on OS X.
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.
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 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.
Blocks: 1387425
(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)
(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)."
Concerning the initial problem raised by this bug report, the implemented API doesn't solve it.

A requirement was being able to set a different name for each window, that wouldn't change while browsing different pages.

- It's still impossible to display the page title in the tab bar while hiding it in the window's titlebar.
- The titlePreface is ignored on pages where document.title=="".
- Some pages won't get their title changed (e.g. about:addons)

With FF 57 approaching, it's a matter of live or death for my extension (FireTitle).
Flags: needinfo?(bob.silverberg)
A solution would be to fix the "doesn't work on pages with no title" and add an option to toggle display of the original title.

FireTitle has more than 2000 users, it tops at 2500 on good days. It means all those users would miss this feature.

Please fix it, you've already done the largest part of the work…
(In reply to Fabien Givors from comment #41)
> Concerning the initial problem raised by this bug report, the implemented
> API doesn't solve it.
> 

It was discussed and decided that being able to add a preface to the title (as opposed to changing the entire title to an arbitrary string) was preferable and does meet most of the use cases for this feature, and that is what has been implemented.

> A requirement was being able to set a different name for each window, that
> wouldn't change while browsing different pages.
> 
> - It's still impossible to display the page title in the tab bar while
> hiding it in the window's titlebar.

I don't understand what you mean by this. What exactly do you want/need to do?

> - The titlePreface is ignored on pages where document.title=="".

This only seems to be an issue on Windows and bug 1387425 has been opened for this. It also feels like an edge case that isn't that important to address, as most windows do have titles.

> - Some pages won't get their title changed (e.g. about:addons)

I am not seeing this behaviour on OS X, and about:addons does have a title, so I would expect the preface to be added on Windows as well. AFAICT it is only windows without titles that do not get prefaced.

> 
> With FF 57 approaching, it's a matter of live or death for my extension
> (FireTitle).
Flags: needinfo?(bob.silverberg)
(In reply to Bob Silverberg [:bsilverberg] from comment #43)
> (In reply to Fabien Givors from comment #41)
> > Concerning the initial problem raised by this bug report, the implemented
> > API doesn't solve it.
> > 
> 
> It was discussed and decided that being able to add a preface to the title
> (as opposed to changing the entire title to an arbitrary string) was
> preferable and does meet most of the use cases for this feature, and that is
> what has been implemented.
Yes. And it almost work (see below), thanks for that. But now, the amount of changes to do to make the initial addon to work has been drastically reduced. Maybe would it be possible to reconsider implementing the remaining features so that FireTitle could be ported to WebExtensions.

> I don't understand what you mean by this. What exactly do you want/need to
> do?
I want to be able to name windows and give them a custom name so that a Window could easily be identified (either visually or by a program) and display customized informations.

For example, if the user wants a window to be called "Work", he can just set the window's title to "Work".
If the user wants a window to be called "eShop - {Number of oppend tabs} - {Title of the active tab}" he just has to set a pattern and its displayed the way he wants.



> > - The titlePreface is ignored on pages where document.title=="".
> 
> This only seems to be an issue on Windows and bug 1387425 has been opened
> for this. It also feels like an edge case that isn't that important to
> address, as most windows do have titles.
No, it's also a problem on Linux. When the document.title is "" (e.g about:blank), then title Preface is ignored and the window's title is "Mozilla Firefox".

> > - Some pages won't get their title changed (e.g. about:addons)
> 
> I am not seeing this behaviour on OS X, and about:addons does have a title,
> so I would expect the preface to be added on Windows as well. AFAICT it is
> only windows without titles that do not get prefaced.
Sorry, I was not precise enough. I meant neither a user nor an extension can change the title of about:addons. So, the prefix-thing work, but I can't do anything to set the window's title to e.g. "Work".
(In reply to Fabien Givors from comment #44)
> (In reply to Bob Silverberg [:bsilverberg] from comment #43)
> > (In reply to Fabien Givors from comment #41)
> > > Concerning the initial problem raised by this bug report, the implemented
> > > API doesn't solve it.
> > > 
> > 
> > It was discussed and decided that being able to add a preface to the title
> > (as opposed to changing the entire title to an arbitrary string) was
> > preferable and does meet most of the use cases for this feature, and that is
> > what has been implemented.
> Yes. And it almost work (see below), thanks for that. But now, the amount of
> changes to do to make the initial addon to work has been drastically
> reduced. Maybe would it be possible to reconsider implementing the remaining
> features so that FireTitle could be ported to WebExtensions.
> 
> > I don't understand what you mean by this. What exactly do you want/need to
> > do?
> I want to be able to name windows and give them a custom name so that a
> Window could easily be identified (either visually or by a program) and
> display customized informations.
> 
> For example, if the user wants a window to be called "Work", he can just set
> the window's title to "Work".
> If the user wants a window to be called "eShop - {Number of oppend tabs} -
> {Title of the active tab}" he just has to set a pattern and its displayed
> the way he wants.
> 

My initial response to you explains that we have no plans on allowing the entire page title to be changed, only the option to add a preface will be implemented. In your first example, the user can preface the window with "Work", which should be enough to allow them to identify it. Your second example, with the template string, will not be supported.

> 
> 
> > > - The titlePreface is ignored on pages where document.title=="".
> > 
> > This only seems to be an issue on Windows and bug 1387425 has been opened
> > for this. It also feels like an edge case that isn't that important to
> > address, as most windows do have titles.
> No, it's also a problem on Linux. When the document.title is "" (e.g
> about:blank), then title Preface is ignored and the window's title is
> "Mozilla Firefox".
> 

I hadn't re-read bug 1387425 when I made that comment, and I recalled incorrectly that the problem only exists on Windows. It is a bit less of a problem on Linux (as described at https://bugzilla.mozilla.org/show_bug.cgi?id=1387425#c1) but you are correct that the problem manifests on both platforms.

> > > - Some pages won't get their title changed (e.g. about:addons)
> > 
> > I am not seeing this behaviour on OS X, and about:addons does have a title,
> > so I would expect the preface to be added on Windows as well. AFAICT it is
> > only windows without titles that do not get prefaced.
> Sorry, I was not precise enough. I meant neither a user nor an extension can
> change the title of about:addons. So, the prefix-thing work, but I can't do
> anything to set the window's title to e.g. "Work".

Ok, so that's really just restating the same issue as your first point, which is that you'd like to be able to replace the entire title, and not just preface it.

I doubt that that is something that is going to be supported, and I can pretty much guarantee it won't happen in time for 57 if it happens at all. Although it seems like we've already made a decision on that, you can file a separate bug requesting that specific feature and we can see if it's something we can consider for a future release.
Ok, thanks for you help. For reference, I just opened bug 1396010 for this feature request.
Depends on: 1396017
Blocks: 1402399
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: