Open Bug 1658775 Opened 9 months ago Updated 3 months ago

dom.disable_window_open_feature.toolbar no longer works


(Core :: DOM: Core & HTML, defect, P5)

79 Branch





(Reporter: cwal, Unassigned)




(Keywords: regression)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

Opened a pop up window on my bank that referenced a different domain which did not have whitelist rules yet in umatrix. I could not see the toolbar and thus could not fix the whitelist to enable the page to work.

Actual results:

The popup window did not show the toolbar even though this preference was set to true.

Expected results:

I have this setting to true. In previous versions of firefox, this means that websites cannot disable to toolbar. It is critical that the toolbar be always visible, as umatrix is accessible from this toolbar, and many websites require tweaking.

Regardless of my specific use case, if a preference has been set, it should actually do something.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core
Regressed by: 1507375

after bug 1507375, website cannot control the each UI-parts visibility with, and it cannot open non-popup new window.
It can open either a popup window, or a new tab, depending on features parameter of [1].
Thus the related prefs to control the features parameter have been removed.

Then, the root cause here is different than the pref or whether to open popup or not,
but the fact that extension system (browser action) isn't integrated into popup window.
(thus you had to workaround by the pref)

that seems to be true also on other browsers (Google Chrome, Safari).


Severity: -- → S4
Priority: -- → P5
Depends on: 1658956

filed bug 1658956 for the problem that browser action isn't available on popup window.

It looks like extensions are supposed to provide page action for such case.

Use a page action when the action relates to the current page.
Use a browser action when the action relates to the browser as a whole or to many pages.

“Regardless of my specific use case, if a preference has been set, it should actually do something.”

The bug still exists.

To be clear, I want control over how my browser chrome looks, I don’t want web pages to be able to change it. This is a regression from the way Firefox used to function.

IMO, that part is WONTFIX.
The pref controls the previous behavior about letting website controls each UI parts' visibility, and the behavior is removed and now website cannot control each UI parts' visibility, but just choose either popup or not.

So would the correct way to report this be to file a regression that Firefox no longer (easily) allows the user to specify that they don’t want websites to mess with their chrome?

It used to be a simple about:config. Now I have to dig even deeper and make a change to userchrome.css. I’m worried that eventually I won’t even be “allowed” to do that, or the method will change and I’ll have to chase down new css rules or other methods.

I have always had Firefox set up this way. I do not want websites to change my chrome, and I know I’m not the only person who feels this way.

fwiw, for the specific use-case about uMatrix, I found the following issue (which is closed tho):

and there's workaround, linked from the above issue:

See bug 1657738 for the discussion about modifying popup window's behavior,
that includes introducing more UI parts into popup window.

Confirming this is a bug, insofar as a user setting this preference should reasonably expect it to apply to popup windows as per documentation:

The solutions I see are:

  • the about:config option could be removed
  • update documentation to say it sometimes doesn't work (and under what conditions it does/doesn't apply)
  • or the feature should be restored.

Personally, I dislike untrusted websites being able to control any window properties outside the space allocated to webpages. Therefore I would push for the 3rd option.

Also, other similar features such as dom.disable_window_open_feature.personalbar have the same issue.

I just realised that the link in the above comment is community documentation, not official documentation.
However, I still have the stance of "why let a website dictate a browser's chrome?" Especially when there are downsides (e.g. some add-ons need workarounds if the toolbar is missing).

As a side note, my current workaround is to set

and then move the newly opened tabs to a new window (if required). This is less than perfect though, because there isn't a way to do this and keep the intended window size.

I agree that this is a massive regression and should be fixed ASAP.

I also don't understand how anyone can defend moves like this. As @cwal said:

I want control over how my browser chrome looks, I don’t want web pages to be able to change it.

Whatever happened to Firefox empowering the user rather than forcing the user to obey whatever terrible usability patterns a random website wants to force upon them?

How far Firefox has fallen since the days of this kind of customisation was not only default, but had an actual GUI in the settings area:

See Also: → 1693450
You need to log in before you can comment on or make changes to this bug.