1373490 - Webextension add-on popup/panel/subview size is not controllable when it is in the overflow/hamburger menu

Status: RESOLVED DUPLICATE of bug 1783972

(WebExtensions :: Frontend, defect, P3)

Description

[Nikolay Martynov]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170612121707

Steps to reproduce:

Install https://addons.mozilla.org/en-US/firefox/addon/secure-password-generator/.


Actual results:

If button for that extention is on the bar then window has one size. If ones mores that button into the menu - window has different size and content doesn't fit.


Expected results:

Popup window size should not depend on the button location.

I'm an author of this extension and current behaviour makes it hard to design extensions that work properly when placed in the menu without placing severe restrictions on the contents of popups. This also doesn't seem to be compatible with Chrome.

Comment 1

[:shell escalante]

Hi Gijs,

Do you know where the overflow menu in Photo is going or plans around it?

Comment 2

[:Gijs (out for now; he/him)]

(In reply to :shell escalante from comment #1)
> Hi Gijs,
> 
> Do you know where the overflow menu in Photo is going or plans around it?

I don't really understand the question. The system for showing subviews for buttons (whether add-on- or browser-provided) will remain the same, it'll just live in a different panel. The webextension framework could work around this by making clicking the button show its own panel instead. This is what happens today if you try to, for instance, open the downloads panel when the downloads button is inside the overflow panel.

My understanding is that what this bug is talking about is a well-known limitation of these views, so I kind of assume it's a duplicate...

Comment 4

[:Gijs (out for now; he/him)]

Would it make sense to show a separate panel rather than a subview for add-on-provided panels that do not fit inside the main panel, when the add-on button is shown in the panel?

(Also, is this perhaps a duplicate? My understanding is this limitation has existed for a long time so I was a bit surprised I couldn't find other bugs on file about it.)

Comment 5

[Andrew Swan [:aswan]]

Sorry, I don't know much about how popups are implemented.  I could stumble my way through it but Kris already knows it inside and out so redirect to him...

Comment 6

[u287251]

An issue related to the one here has been reported on my issue tracker:
https://github.com/gorhill/uBlock/issues/2809

My extension's panel has two sizes, and depending on the size it's being rendered, the panel will be either:

- horizontally too narrow to fill the overflow menu (visually unpleasant)
- horizontally truncated to the point of being unusable

Because the overflow panel appears to be fixed width.

The issue is with the webext version of the extension.

The legacy version does not suffer the issue because it is able to gather outside knowledge[1] which is not available to webext extensions.

Just throwing an idea:

If the popup panel of a webext version was able to get some sort of knowledge about how it is being rendered, then it would be possible to make CSS rules to adjust for the visual constraints imposed by the framework. For example, if the webext framework could set a predefined class name on the html element of the panel for the special case of being rendered inside a width-constrained placeholder, extension authors could deal with this with plain CSS rules.

***

[1] Using a `portrait` class name when rendered inside a CustomizableUI.TYPE_MENU_PANEL widget.

Comment 7

[:Gijs (out for now; he/him)]

(In reply to R. Hill from comment #6)
> Just throwing an idea:
> 
> If the popup panel of a webext version was able to get some sort of
> knowledge about how it is being rendered, then it would be possible to make
> CSS rules to adjust for the visual constraints imposed by the framework. For
> example, if the webext framework could set a predefined class name on the
> html element of the panel for the special case of being rendered inside a
> width-constrained placeholder, extension authors could deal with this with
> plain CSS rules.


@media screen and (min-width: ...) {

}

or max-width... should be able to do what you want. From JS, you could also compare window.innerWidth and document.documentElement.clientWidth (or offsetWidth? I forget...), I think.


I think we don't intend to change anything here, but Kris can confirm.

Comment 10

[:Gijs (out for now; he/him)]

Apparently scrolling the popups doesn't work either (from the latest dupe). Andy, can we get this prioritized if we want to do something (like, at a minimum, allowing scroll by overriding the popup.css html selector that disables it here), or do outreach to developers so they don't make panels that are too wide?

Comment 11

[Nikolay Martynov]

'or do outreach to developers so they don't make panels that are too wide'

In my humble opinion this seems a bit harsh. Popups are used essentially as a replacement for pop up windows in XUL addons - which could be of any size. With move to webextentions popup windows are no longer available and if webextention popup size is so severely restricted they are not a replacement for old windows either.

Comment 13

[:Harald Kirschner :digitarald]

This affects most of my popups. It seems risky to expect developers to re-work their addons. This has higher impact now that it is easier to move icons into the overflow.

Comment 15

[Andy McKay]

Can't need info you Markus, so cc'ing you instead.

Comment 17

[Markus Jaritz [:designakt] (UX)]

Keeping the width of the overflow allows users to know where to expect the back button in the top left. As soon as we start stretching the panel, this button moves, which makes it more difficult to click reliably.
Moving an extension to the overflow is a user initiated action, and can be seen as intent to have the button filed away, but still accessible on certain cases. So having the extension react to that user intent is the desired behavior. By now responsive design is such an integral part of web design that I would expect developers should be able to handle that. At least for most broadly used extensions (where I would not expect too intense interfaces that justify giant panels.) And panels that are smaller by default are even less of a problem.

I however would propose an escape hatch for extensions that can not, or do not want to care about the width-limitation the user initiated when moving the extension into the overflow, as for some more advanced interface a bigger UI might be necessary.
Maybe a value to set to ignore the overflow, which will make the extension open a panel hanging directly from the overflow, instead of as a second level to the overflow menu. like this:

browser.browserAction.setPopup(
  details        // object
    tabId        // (as in doc)
    popup        // (as in doc)
    overflow     // (optional) string ("observe"(default) or "ignore")
)


This is something that might need some UX comment in the documentation to help developers decided for the right ways, and not just choose "ignore" as the lazy option to not have to care about fitting with Firefox.

(I feel like I might have missed an aspect of this or am maybe not familiar with all limitations around developing extensions. Please tell me if that is the case.)

Comment 19

[mrmr1993]

This issue affects Vimium-ff's pop-ups.

I am advising affected users that the double-chevron menu is broken, and Vimium should not be used with it.

We have no plans to support the current behaviour.

Comment 21

[nrlz]

(In reply to Markus Jaritz [:designakt] (UX) from comment #17)
> By now responsive design is such an integral part of web
> design that I would expect developers should be able to handle that.

The problem is popup pages and hamburger menu pages have different sizing methods.

The hamburger menu popup is the traditional way where content grows or shrinks depending on the viewport size.
But the popup way requires content to have a "preferred size" or "minimum size" in order for Firefox to size the popup properly.

Some content don't have a minimum size, like photo albums where pictures can be resized, and it is unreasonable to set a tiny minimum size like 100px knowing that if it shows up in a popup, the popup will assume that 100px is the preferred size.

If I specify a preferred size with "body{width:500px}", then if it is loaded in the hamburger menu page it will be too large.
If I specify the minimum size with "body{width:100px}", then if it is loaded as a popup page, it will look too small.

Comment 22

[Johann Hofmann [:johannh]]

I've been watching this for a bit but I have yet to see an extension that looks good when placed in the chevron menu. Let's revive this bug.

(In reply to Markus Jaritz [:designakt] (UX) from comment #17)
> Keeping the width of the overflow allows users to know where to expect the
> back button in the top left. As soon as we start stretching the panel, this
> button moves, which makes it more difficult to click reliably.

Is it really worth standing our ground on this simple argument vs. "all developers have to rewrite their styles to adjust to Firefox-exclusive additional panel edge cases"? Can't we just give in and find a way to show the extension panel in full-width?

> Moving an extension to the overflow is a user initiated action, and can be
> seen as intent to have the button filed away, but still accessible on
> certain cases. So having the extension react to that user intent is the
> desired behavior. By now responsive design is such an integral part of web
> design that I would expect developers should be able to handle that. At
> least for most broadly used extensions (where I would not expect too intense
> interfaces that justify giant panels.) And panels that are smaller by
> default are even less of a problem.

Besides the purely technical issues from comment 21, none of the authors of existing extensions were aware that responsive design was ever going to be a requirement for writing an extension popup. As a result, many popups are styled in a way that doesn't invite for just dropping in some media queries and be done with it. In some cases it may require an entirely new concept for their UI. We shouldn't dismiss the work required here.

> I however would propose an escape hatch for extensions that can not, or do
> not want to care about the width-limitation the user initiated when moving
> the extension into the overflow, as for some more advanced interface a
> bigger UI might be necessary.
> Maybe a value to set to ignore the overflow, which will make the extension
> open a panel hanging directly from the overflow, instead of as a second
> level to the overflow menu. like this:
> 
> browser.browserAction.setPopup(
>   details        // object
>     tabId        // (as in doc)
>     popup        // (as in doc)
>     overflow     // (optional) string ("observe"(default) or "ignore")
> )
> 
> 
> This is something that might need some UX comment in the documentation to
> help developers decided for the right ways, and not just choose "ignore" as
> the lazy option to not have to care about fitting with Firefox.

We should just make this the default and not add an option. There are a lot of problems with this sort of optional argument. It is entirely implementation-specific and is bound to become dead code once the panel changes or the underlying problem is fixed. It requires virtually all add-on authors to update their extensions. Also, as you were saying, it is most likely that most authors will just go with "ignore" and get on with their lives (me included). There is little incentive to support the chevron menu as a first-class citizen, considering the costs this entails.

Can we move forward on this bug, please? IMO it's having a negative impact on Photon.

Comment 23

[Markus Jaritz [:designakt] (UX)]

Reading nrlz comment and talking with Johann, I understand that my statement about responsive design has been wrong, as we do not provide a way for devs to adapt to those 2 different sizes.
Therefor I think, our next step should to find a solution that enables extension devs to easily allow for resizing when the extension is in the overflow. Without that we can not expect devs to make their extension work in both cases.

I wonder how we solved for this pre 57, when menus like History or WebDeveloper could be in the menu, or in the toolbar, and therefor use 2 different sizes as well.

Comment 24

[magicp]

Attachment: webextensions-popup-size.png

There are 3 different sizes in 58.

Comment 25

[nrlz]

(In reply to Markus Jaritz [:designakt] (UX) from comment #23)
> Reading nrlz comment and talking with Johann, I understand that my statement
> about responsive design has been wrong, as we do not provide a way for devs
> to adapt to those 2 different sizes.
> Therefor I think, our next step should to find a solution that enables
> extension devs to easily allow for resizing when the extension is in the
> overflow. Without that we can not expect devs to make their extension work
> in both cases.

The solution I'm using is easy:

I set the preferred size on the body which is picked up by the popup opener:

body {width:500px; height:500px}

Then all my content goes inside an absolutely positioned div with top/right/bottom/left set as 0px. This means it shrinks or expands to fit the visible viewport:

#container {position:absolute; top:0; right:0; bottom:0; left:0}

And corresponding HTML in case it isn't clear:

<body>
<div id=container>stuff</div>
</body>

Comment 26

[Andy McKay]

It was pretty bad pre-photon too. Some of my add-ons didn't look great then either. 

As a user with extensions in the overflow menu, the real value of having the browserAction in the overflow menu is not how the menu reacts or move. But rather that I'm choosing between a one and two click flow to get to the browserAction. I move add-ons that I use a lot into the menu bar and the others into the overflow menu.

I might be missing some of the nuance in sizing here, but I would suggest we just change the menu to whatever size the extension author has asked for in their browserAction.

Comment 27

[Markus Jaritz [:designakt] (UX)]

Aaron, how did you expect the overflow menu to handle extensions in various sizes when you created the overflow.

Comment 28

[Aaron Benson]

Hey Markus, we should probably allow for the sub-panels to widen in the case of extensions in the overflow so it doesn't break the experience. We'll take a look at this but probably won't make 57.

Comment 29

[Andy McKay]

Not making 57 sounds reasonable, should we assign it to someone on your team Aaron? Also clearing out kmag ni since I think we've got a solution here.

Comment 30

[Aaron Benson]

Mike added it to our triage so it'll get looked at. Thanks Andy!

Comment 32

[:Gijs (out for now; he/him)]

(In reply to Aaron Benson from comment #28)
> Hey Markus, we should probably allow for the sub-panels to widen in the case
> of extensions in the overflow so it doesn't break the experience. We'll take
> a look at this but probably won't make 57.

Is there a separate bug for the design work for this? Making the popup transition not look crap when animating both width and height (and keeping the anchoring in place) is going to be... challenging.

Comment 33

[Aaron Benson]

No design specifically for it -- I was hoping we could test it out in code. The behavior should work as you described it by animating the width and height.  

Another option we might consider is popping the web extension out in it's own window. I noticed that 1Password does this already and the UX isn't that bad. We might consider putting a title bar with a close button on more standard web extensions. Lets wait to consider this particular option backup plan if the transitions prove to be problematic.

Comment 40

[Andreas Klauer]

My bug #1434149 got marked as a duplicate of this one, so I'd like to point out here, that long titles cause the same issue.

The overflow menu always displays a title bar (browserAction.setTitle()) and that seems to stretch the popup content but only shows half of it on screen in the end, independent of the popup's own style.

Obvious workaround in this case: set a shorter title.

> Moving an extension to the overflow is a user initiated action, and can be seen as intent to have the button filed away

Users can manually pin addons to the overflow, however it also happens unintended as addons move into the overflow on their own accord when the browser window is resized, or there simply are too many addons installed to make them all fit.

If possible, I'd prefer overflow addons to behave the same as regular addons, no decorations with title and back button. Addons that need titles shown already do that (example uBlock Origin always shows addon name and version number on top), in the overflow case, that results in duplicated information.

Overflow menu could show a list of icons (titles as tooltips as it were), and the selected popup icon could temporarily take the place of the overflow icon while the popup is open. So to the open popup, it's as if the overflow didn't exist. Didn't older firefox have something like this?

Popups close so easily (sometimes even unintentionally), and directly switching between two addons also seems unusual to me... by the time you want to user another addon, the previous popup is long gone so whoever wants to go back to the overflow menu could also simply select the double-chevron icon again.

Showing the popup regularly should result in fewer corner cases? No idea.

Thanks.

Comment 41

[Giorgio Maone [:ma1]]

NoScript doesn't just look bad, it's completely unusable from the overflow menu.
Is there any progress here, or any suggested work-around (other than reaching out every single user reporting this behavior as an extension bug and suggesting them to move the browser action icon on the far left of the toolbar, so that it cannot fall in the overflow area)?
Is there even any way to detect this is happening and spawn an alternate popup window, instead of the browserAction's regular popup?

Comment 42

[:Gijs (out for now; he/him)]

(In reply to Giorgio Maone [:mao] from comment #41)
> Is there even any way to detect this is happening and spawn an alternate
> popup window, instead of the browserAction's regular popup?

You can use media queries, or (from JS) window.matchMedia() to check for the window size.

Comment 43

[Andreas Klauer]

(In reply to :Gijs from comment #42)
> You can use media queries, or (from JS) window.matchMedia() to check for the window size.

But that's the problem, it reports a much larger size (and the popup actually _is_ that large too) but the visible area is simply cut in half and the other half is just white nothingness. There is no way to detect it and neither should it be necessary to add support for this in an extension. 

It's a bug. Only workaround for extensions is to stop using popups altogether and spawn a new tab or standalone dialog window directly. It shouldn't be like that.

Comment 44

[:Gijs (out for now; he/him)]

(In reply to Andreas Klauer from comment #43)
> (In reply to :Gijs from comment #42)
> > You can use media queries, or (from JS) window.matchMedia() to check for the window size.
> 
> But that's the problem, it reports a much larger size (and the popup
> actually _is_ that large too)

This would only happen if you have content in there that is forcing the body to be that wide. In other words, if you put the same document in a browser window and resized it, you would see horizontal scrollbars. As I noted in comment #10, the lack of visible scrollbars in this case is a bug (and should be relatively easy to fix, but likely won't help people all that much)...

> but the visible area is simply cut in half and
> the other half is just white nothingness.

This sounds like a graphics issue to me, but it's hard to be sure.

> There is no way to detect it

Well, here's a really really simple thing I just wrote:

<p id="w"></p>
<p>I am a document with a bunch of text. The text wraps depending on the width of the frame I am
included in. Of course, if I force something to be wide, then that will create overflow.
<script>
  setInterval(function() {
    document.getElementById("w").textContent = window.document.body.clientWidth;
  }, 3000);
</script>


if I use this as the browser action popup document, outside of the overflow menu the width displayed is 800. In the overflow menu, on my machine, it's 319 (ymmv, the exact number is em-size-dependent). In both cases, the text wraps, just at different points. If you see constant numbers, as I pointed out earlier, that's because the content in your popup is forcing a particular size.

> and neither should it be necessary to add support for this in an extension. 

I don't really want to comment on this either way; it's up to the webextension folks to prioritize this and how they fix it. I will point out that even outside the overflow menu there is a limit to the width of the popup (namely 800px), and if your display was smaller the limit would be still smaller.

Comment 45

[Andreas Klauer]

Attachment: half-hidden-overflow-popup.png

(In reply to :Gijs (under the weather; responses will be slow) from comment #44)
> Well, here's a really really simple thing I just wrote:

Made a screenshot of your really simple thing. Half is visible, half is hidden.

(In reply to Andreas Klauer from comment #40)
> My bug #1434149 got marked as a duplicate of this one, so I'd like to point
> out here, that long titles cause the same issue.

Comment 46

[:Gijs (out for now; he/him)]

(In reply to Andreas Klauer from comment #45)
> Created attachment 8956850 [details]
> half-hidden-overflow-popup.png
> 
> (In reply to :Gijs (under the weather; responses will be slow) from comment
> #44)
> > Well, here's a really really simple thing I just wrote:
> 
> Made a screenshot of your really simple thing. Half is visible, half is
> hidden.

Are you pinning it to the overflow menu, or just resizing the window? In the latter case, I think you're actually technically running into bug 1383294 - though the more dupes there are, the less it maybe really makes sense to treat the issues separately, even if in terms of code fixes there are probably really 2 things to fix.

Comment 48

[Lusito]

Both of my extensions have problems with this issue.. I only found out about it because someone reported it, as I don't use the overflow menu. That this happens at all is a very well hidden fact.

Shouldn't this be easy to fix by just showing the extension popup the normal way, just like the downloads button gets shown normally as well?

I tried to remove the popup from the manifest and set/open the popup on click, but sadly, that didn't work.

Comment 49

[djones109+git]

As a user, I've been pretty annoyed by this bug since switching back to Firefox from Chrome some time ago. It might be worth it to look at Chrome's behavior in the same situation.

In Chrome, when I use one of the addons in the hamburger menu, after clicking it, the button is temporarily moved to the toolbar, and it's shown in its proper size.


I have identical addons that I use on both Chrome and FF. I like to only keep the addons that show me relevant information (such as notifier addons) visible, and keep all others in the Overflow menu.

When I do need to use these addons, I need the full popup to be visible. From a user's perspective, it shouldn't really make a difference whether the button is in the toolbar, or in the Overflow menu. For all intents and purposes, the Overflow menu appears to be a part of the toolbar, and should certainly behave the same way.

Comment 50

[Ghostbird]

An additional issue that happens with NoScript, but might be unrelated:

I usually used NoScript from the context menu. The new WebExtensions NoScript has an option to add a button to the context menu to open the NoScript dialogue. However, when the button is located in the overflow menu, the pop-up doesn't show the domain names, since it is weirdly truncated (either too small, or wide enough, but with the content is still truncated to the smaller size and the rest is white).

Even worse. When the NoScrip add-on button is not added to the UI, clicking the NoScript button in the context menu does ABSOLUTELY NOTHING!

This annoys me, because I MUST have a button in the UI, explicitly to NOT HAVE TO USE IT (if that makes sense). What I mean is that, if I want to use the context menu button rather than the normal UI button, I must add the UI button. It's extremely counter-intuitive, and a waste of UI space.

In fact due to this bug I am not using the overflow menu at all. I have three add-on buttons that I want to put in a position where the add-on menu will still work (it won't work if the button isn't in the UI, and I try to open the add-on menu with a hot-key or context-menu button). Two of these add-on buttons suffer from this bug, and hence must be added to a toolbar directly. The third one (Greasemonkey) works well with the overflow menu, but having only one item in the overflow menu is pointless, and I can just replace the overflow menu button with the Greasemonkey button directly.

As I understand it the move to WebExtensions has several good reasons, but these kind of weird things make it seem very poorly thought-out in terms of user interface. Especially the fact that you need a button in the UI to not have to use it is extremely puzzling.

Comment 51

[David Durst [:ddurst]]

Setting to P2 for near-term addressing beginning in Q4 or Q1.

Comment 53

[Theraten]

The popular Pushbullet Extension is also affected by this error. I hope there will be a fix in the next Firefox release.

Comment 54

[jazcue]

Hasn't this problem already been solved by Chrome? Why not use the same approach? Temporarily shift the extension button back up into the main toolbar on button click, so that the standard extension popup window is rendered off the main toolbar. This simplifies the design tremendously by eliminating the need for extensions to conform to the restrictions of the overflow menu dimensions and eliminates the need for navigation within the overflow menu.

Comment 56

[lolipopplus]

As an extension developer, I just wanna say: wowwwwwwwwwwwwww
As a user: excuse me?

But I hope there is more explanation about how in the world this can be 2 yrs old.

And if there is something really hard, I think you guys should post something on MDN about things that addons developers can do to avoid this.

Comment 57

[Kenny]

Agreed. I keep hoping there will be a fix. Some extensions are completely broken when placed in the overflow menu. Snooze Tabby, Form History Control.... the list goes on and the only current alternative is to have these extension icons cluttering up your toolbar.

Comment 60

[Michael Heyns]

Attachment: 1passwordx.png

I just wanted to mention another addon affected by this issue: 1PasswordX.

Corresponding discussion here.

Comment 61

[Robert AB]

This bug is needed to be fixed for Tab Session Manager:
https://github.com/sienori/Tab-Session-Manager/issues/436#issuecomment-529357577

Comment 63

[TheRave]

This bug will be more important with the new megabar or quantumbar. It was enabled automatically with firefox 71 nightly. All toolbar buttons moved into Hamburger menu on left side and the resulting popup window of the toolbar buttons have a restricted size. It is high time to set this bug as P1 with target firefox 71.

Comment 64

[Sören Hentzschel]

(In reply to TheRave from comment #63)

This bug will be more important with the new megabar […] It is high time to set this bug as P1 with target firefox 71.

The megabar won't be shipped before Firefox 72.

Comment 66

[TheBinocular]

Sorry for advocacy but this is still very much a problem, 4 years later.

It's a user-facing bug. It affects every single add-on developer how has to work around this. It breaks the usability of any add-on that doesn't account for this bug.

To add to that, it doesn't even make sense to restrict the size of this menu in the first place.

Please make this a higher priority.

Comment 67

[alex_mayorga]

Attachment: image.png

¡Hola y'all!

Per Gijs at https://matrix.to/#/!rHHMKzcUcGkdujJeis:mozilla.org/$62k5PT4rh6KYQCUy-ZhffQl7X5l0naeYu3udYkAEWZ0?via=mozilla.org&via=matrix.org&via=fairydust.space this one bite me on 89.

So updating flags FWIW.

¡Gracias!
Alex

Comment 69

[Dym Sohin]

shortcut workaround i found while solving related issue:

@media (width: 302px) {
  /* re-layout for pinned window */
}

Comment 70

[Dym Sohin]

(In reply to Dym Sohin from comment #69)
acly nvm, every fractional dpi will have different number: 302, 194, or even 0 :D

Comment 71

[sami.vanttinen]

I managed to solve this with KeePassXC-Browser in a way that it reads the document.body.offsetWidth and sets the popup to default size using JavaScript if it's too small. Default size meaning there the popup size in overflow menu. Non-Firefox browsers doesn't have it, so with those the normal size is always set. The content must be of course set dynamically. Flex handles it nicely.

Also, if you set the popup width or min-width the Firefox overflow menu breaks again. And when those are not set, non-Firefox browsers break the whole popup, because those browsers expect that the popup has some size specififed. So another little script is needed to set the default size when the popup is loaded with non-Firefox browsers.

Not a perfect solution because it still sometimes shows the overflow popup content too big if the rendering is slow (for example with virtual images).

Comment 73

[Shane Caraveo (:mixedpuppy)]

This set of issues is resolved by popping browser actions out of the overflow button when opened.