1280128 - popup background color does not extend to corners

Status: RESOLVED FIXED

(WebExtensions :: Untriaged, enhancement, P1)

Description

[Hans Meyer]

Attachment: ff_popup.png

When setting a background color on the body tag of a popup, the color does not extend all the way into the corners of the popup. It appears that the popup content has rounded corners whereas the popup itself does not. See attachment.

I suspect this is platform specific, but I have only tested on Windows 10.

Additionally:

It would be a nice touch for the popup nib to inherit the background color instead of always being white. While Chrome does not do this, it's slightly less objectionable there since their popups also always have a white border (on Windows at least). I think FF's full-bleed aesthetic is much nicer, though.

Comment 1

[:shell escalante]

how important is this from UX perspective - so we can prioritize.

Comment 2

[Markus Jaritz [:designakt] (UX)]

Attachment: ff_popup_fix.png

Wow, this is odd behavior. It does not limit functionality but it is a very visible bug that will significantly deter from the extensions perceived quality. I would consider this a P1 as I can not see how devs could build quality extensions with this bug in place.

I also agree with the additional point. Having the background of the actual panel colored would be even better, as it would hopefully also color the white area on the opening of the panel. P2
Leading to a desired look of the panel something like what I attached.

Comment 3

[drhen123]

If it is not possible to be able to colour the background panel then would a solution be to make it transparent negating the visible difference.

Comment 4

[Blake Winton (:bwinton) (:☕️)]

I agree with Markus's assessment.  Also, there's no workaround, which I feel makes it higher priority than it would otherwise be.
(Yeah, I'm commenting mostly to clear my needinfo request.  ;)

Comment 5

[Kris Maglione [:kmag]]

Attachment: Bug 1280128: [webext] Use transparent backgrounds and padding for popup browsers. ui-r?maritz

Review commit: https://reviewboard.mozilla.org/r/65760/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/65760/

Comment 6

[Kris Maglione [:kmag]]

Comment on attachment 8773124 [details]
Bug 1280128: [webext] Use transparent backgrounds and padding for popup browsers.  ui-r?maritz

Screenshots on Linux with transparent and non-transparent popup backgrounds:

https://people.mozilla.org/~kmaglione/images/6b02ca18631abe4d.png
https://people.mozilla.org/~kmaglione/images/371196d85b6af0e0.png

I haven't been able to test on Windows or OS-X yet.

Extending the background color of the page to the popup itself is a much bigger task, which will need a separate bug.

Comment 7

[Kris Maglione [:kmag]]

Screenshots for OS-X:

https://people.mozilla.com/~kmaglione/images/b9985d497bf146ff.png
https://people.mozilla.com/~kmaglione/images/0ac2b826743116d9.png
https://people.mozilla.com/~kmaglione/images/5a4ceeacb3a2766a.png
https://people.mozilla.com/~kmaglione/images/48fe2d97044fbd1f.png

Comment 8

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 8773124 [details]
Bug 1280128: [webext] Use transparent backgrounds and padding for popup browsers.  ui-r?maritz

https://reviewboard.mozilla.org/r/65760/#review63380

::: browser/themes/linux/browser.css:1924
(Diff revision 1)
>  .browser-extension-panel > .panel-arrowcontainer > .panel-arrowcontent {
>    padding: 0;
>    overflow: hidden;
>  }
>  
> +.webextension-popup-browser {

Is there a common file we could put this in, to avoid duplication?

So, I'm pretty happy with the code, aside from the nit I mention above, but I don't think it looks particularly good with the differently-coloured border.  Having said that, that's more of a ui-review, so I'll let Markus decide if he can live with it, or wants to wait until we can grab the background colour…  But code-wise, r=me.

Comment 9

[Kris Maglione [:kmag]]

https://reviewboard.mozilla.org/r/65760/#review63380

> Is there a common file we could put this in, to avoid duplication?

There is, but we may wind up having to make OS-dependent changes at some point, so I'd rather keep it in OS-specific files.

I'd prefer to use the background color of the page too, but that's a much bigger change, and I want the first version of this to be upliftable. If we can settle on this for now, I'll file a follow-up to handle using the page's background color.

Comment 10

[Markus Jaritz [:designakt] (UX)]

I do not understand why we need a padding around all background a user could create?
Can we just have all background extend all the way to the sides and have round corners on macOS, and sharp corners on Windows? (Like in the mock I attached last time, but without coloring the triangle on top.)

And hopefully get it extended to the triangle on top also in color in a next version... (:kmag are you saying that this should be a separate bug?)

As mentioned on IRC, I too wonder how an add-on dev would implement our recommended default panel appearance if no background could extend to the sides... Would make it impossible to implement a footer with a darker background as we use it in Download and Menu Panels.

Comment 11

[Kris Maglione [:kmag]]

(In reply to Markus Jaritz [:maritz] (UX) from comment #10)
> I do not understand why we need a padding around all background a user could
> create?
> Can we just have all background extend all the way to the sides and have
> round corners on macOS, and sharp corners on Windows? (Like in the mock I
> attached last time, but without coloring the triangle on top.)

The problem is that I don't think that it's safe to extend the browser element
to the edges of the popup and have it clipped by the rounded corners. There
could also be issues with pages that aren't expecting those corners to be
clipped.

Extending the page's background color all the way to the edges is doable, but
that requires some complicated work and definitely won't be upliftable.
Extending the browser itself might be doable, but that needs enough time to
bake in nightlies that we're sure there won't be problems with it.

Using enough padding that the corners of the browser will never be clipped is
reasonably simple and safe, and should be upliftable.

> And hopefully get it extended to the triangle on top also in color in a next
> version... (:kmag are you saying that this should be a separate bug?)

Yes. I'd definitely like to do that, but it's going to take a lot more work.

> As mentioned on IRC, I too wonder how an add-on dev would implement our
> recommended default panel appearance if no background could extend to the
> sides... Would make it impossible to implement a footer with a darker
> background as we use it in Download and Menu Panels.

We'll have to talk a bit more about the details. Hopefully we'll able to make
the browser extend all the way to the edge/corners of the popup, and come up
with some kind of special handling for the arrow.

Comment 12

[Markus Jaritz [:designakt] (UX)]

(In reply to Kris Maglione [:kmag] from comment #11)
> The problem is that I don't think that it's safe to extend the browser
> element to the edges of the popup and have it clipped by the rounded corners.

What would that mean in terms of safety? How would clipping those corners affect safty?

To clarify: do we now need to decide between 2 options for the short term:
- white space outside of rounded corners on windows (current)
- padding all around (would that padding only be used on mac, or on windows too?)

But we will move to a version that extends all the way to the edges with rounded corners on mac, and sharp corners on Windows, and a matching triangle on top.
> We'll have to talk a bit more about the details. Hopefully we'll able to make
> the browser extend all the way to the edge/corners of the popup, and come up
> with some kind of special handling for the arrow.

What versions are we aiming for with both steps?

Comment 13

[Kris Maglione [:kmag]]

(In reply to Markus Jaritz [:maritz] (UX) from comment #12)
> (In reply to Kris Maglione [:kmag] from comment #11)
> > The problem is that I don't think that it's safe to extend the browser
> > element to the edges of the popup and have it clipped by the rounded corners.
> 
> What would that mean in terms of safety? How would clipping those corners
> affect safty?

Not unsafe in terms of security, but in terms of the implementation being
reliable, and not prone to serious visual glitches. Panels tend to be
particularly prone to those as it is. More so when they have browsers in them,
or use clipping, or CSS animations, or transparency effects. Panels on OS-X
already use all of those, and I'm worried about adding clipping of actual
browsers to the mix (in fact, I'm fairly certain our failure to properly clip
the browser is what's causing the problem to begin with).

> To clarify: do we now need to decide between 2 options for the short term:
> - white space outside of rounded corners on windows (current)
> - padding all around (would that padding only be used on mac, or on windows
> too?)

No, I think we need to decide between a) no rounded corners, or b) padding
around the browser so that it isn't clipped by corners.

> But we will move to a version that extends all the way to the edges with
> rounded corners on mac, and sharp corners on Windows, and a matching
> triangle on top.

Yes. Although there's still a question of whether the browser will extend all
the way to the corners, or there will be padding that happens to be a solid
background color.

> > We'll have to talk a bit more about the details. Hopefully we'll able to make
> > the browser extend all the way to the edge/corners of the popup, and come up
> > with some kind of special handling for the arrow.
> 
> What versions are we aiming for with both steps?

Well, I was aiming for 48, but that ship has sailed, so I'm hoping for one
version to be uplifted to 49, and the updated version to ride the trains in
51.

Comment 14

[Markus Jaritz [:designakt] (UX)]

(In reply to Kris Maglione [:kmag] from comment #13)
> 
> I think we need to decide between 
> a) no rounded corners, or 
> b) padding around the browser so that it isn't clipped by corners.

Great, then let us not do rounded corners.

> Although there's still a question of whether the browser will extend all
> the way to the corners, or there will be padding that happens to be a solid
> background color.

Is that question resolved if we're not doing rounded corners?

Comment 15

[Kris Maglione [:kmag]]

(In reply to Markus Jaritz [:maritz] (UX) from comment #14)
> (In reply to Kris Maglione [:kmag] from comment #13)
> > I think we need to decide between 
> > a) no rounded corners, or 
> > b) padding around the browser so that it isn't clipped by corners.
> 
> Great, then let us not do rounded corners.

Works for me.

> > Although there's still a question of whether the browser will extend all
> > the way to the corners, or there will be padding that happens to be a solid
> > background color.
> 
> Is that question resolved if we're not doing rounded corners?

Yes.

Comment 16

[Blake Winton (:bwinton) (:☕️)]

(In reply to Markus Jaritz [:maritz] (UX) from comment #14)
> (In reply to Kris Maglione [:kmag] from comment #13)
> > 
> > I think we need to decide between 
> > a) no rounded corners, or 
> > b) padding around the browser so that it isn't clipped by corners.
> Great, then let us not do rounded corners.

Are we going to change the other popups on Mac (like the Downloads or Bookmarks menu or Identity menu) to not have rounded corners, or are we happy having two different (seemingly-random) panel types there?

Comment 17

[Markus Jaritz [:designakt] (UX)]

(In reply to Blake Winton (:bwinton) (:☕️) from comment #16)
> Are we going to change the other popups on Mac (like the Downloads or
> Bookmarks menu or Identity menu) to not have rounded corners, or are we
> happy having two different (seemingly-random) panel types there?

I do not think that we should change other popups on Mac.
I expect this to be the short term solution. (Having a glitch on Mac, but therefor solving the Windows glitch.)

I still see the full goals as:
(In reply to Markus Jaritz [:maritz] (UX) from comment #12)
> But we will move to a version that extends all the way to the edges with
> rounded corners on mac, and sharp corners on Windows, and a matching
> triangle on top.

But as I understand that full implementation is more complicated.

Comment 18

[Kris Maglione [:kmag]]

I spent some more time on this and came up with some better results:

https://people.mozilla.org/~kmaglione/images/aeb00ab8198ddfca.png

Apparently the corner cropping was the result of Blake's changes in bug 1225633 to fix the failed browser cropping on OS-X, but wound up breaking things on other platforms. Having that cropping applied on OS-X, but not applied elsewhere, seems to solve both problems, so I think we can keep the rounded corners.

Comment 19

[Kris Maglione [:kmag]]

Comment on attachment 8773124 [details]
Bug 1280128: [webext] Use transparent backgrounds and padding for popup browsers.  ui-r?maritz

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/65760/diff/1-2/

Comment 20

[Kris Maglione [:kmag]]

Comment on attachment 8773124 [details]
Bug 1280128: [webext] Use transparent backgrounds and padding for popup browsers.  ui-r?maritz

This version also makes the body background transparent for browser_style popups, and adds a 3.5px border radius to the body of standalone popups on OS-X, so they can detect when their corners are clipped.

Comment 21

[Kris Maglione [:kmag]]

Comment on attachment 8773124 [details]
Bug 1280128: [webext] Use transparent backgrounds and padding for popup browsers.  ui-r?maritz

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/65760/diff/2-3/

Comment 22

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 8773124 [details]
Bug 1280128: [webext] Use transparent backgrounds and padding for popup browsers.  ui-r?maritz

https://reviewboard.mozilla.org/r/65760/#review66960

::: browser/components/extensions/extension.css:14
(Diff revision 3)
>  }
>  
>  /* Variables */
>  html,
>  body {
> -  background-color: #fcfcfc;
> +  background: transparent;

This all looks pretty good, but I'm a little worried about this line…  If we ask for browser style in the popup, I think an unspecified background should be #fcfcfc.  Does that still happen with this change?

r=me with that explained (or changed).

Comment 23

[Kris Maglione [:kmag]]

https://reviewboard.mozilla.org/r/65760/#review66960

> This all looks pretty good, but I'm a little worried about this line…  If we ask for browser style in the popup, I think an unspecified background should be #fcfcfc.  Does that still happen with this change?

It depends. The browser is transparent now, so the background color is now the same as the underlying panel, which varies slightly by platform, and depending on whether we're in a PanelUI subview. It's approximately that color on all platforms, but on OS-X there's a slight gradient, on Linux the color is -moz-dialog, and on Windows it's -moz-field when in a sub-view.

Comment 24

[Blake Winton (:bwinton) (:☕️)]

Okay, that sounds close enough for me.  :)

Comment 25

[Markus Jaritz [:designakt] (UX)]

Sounds great. How will it now look in Windows? 8 & 10 I assume have sharp corners without any visible radius. How does this affect Windows 7? I think it uses rounded corners on panels.

Comment 26

[Kris Maglione [:kmag]]

(In reply to Markus Jaritz [:maritz] (UX) from comment #25)
> Sounds great. How will it now look in Windows? 8 & 10 I assume have sharp
> corners without any visible radius. How does this affect Windows 7? I think
> it uses rounded corners on panels.

Here's what it looks like on Windows 7 with the changes from bug 1293099 (without them, it looks the same, only with the ordinary arrow color):

https://people.mozilla.com/~kmaglione/images/7b6ab40b9d39f22f.png

I don't have Windows 8 or 10 to test with at the moment, but looking at the CSS, I think we should have rounded corners on XP, Vista, and 7, but not on 8 or 10. We only have non-rounded corners in this screenshot because we don't currently use the same trick of cropping the browser corners there that we do on OS-X, so I guess I need to fix that.

Comment 27

[Kris Maglione [:kmag]]

Comment on attachment 8773124 [details]
Bug 1280128: [webext] Use transparent backgrounds and padding for popup browsers.  ui-r?maritz

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/65760/diff/3-4/

Comment 28

[Kris Maglione [:kmag]]

Comment on attachment 8773124 [details]
Bug 1280128: [webext] Use transparent backgrounds and padding for popup browsers.  ui-r?maritz

OK, updated screenshot on Windows 7:

https://people.mozilla.org/~kmaglione/images/4c8326091676ad09.png

I realized this is getting complicated, so I also added tests to make sure things stay in sync on different platforms.

Comment 29

[Markus Jaritz [:designakt] (UX)]

Comment on attachment 8773124 [details]
Bug 1280128: [webext] Use transparent backgrounds and padding for popup browsers.  ui-r?maritz

Looks like we have rounded corners where we need them (XP, Vista, Win 7, Mac), and sharp corners where we need those (Win 8 & 10, Linux). Great. Thanks.

Comment 30

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 8773124 [details]
Bug 1280128: [webext] Use transparent backgrounds and padding for popup browsers.  ui-r?maritz

https://reviewboard.mozilla.org/r/65760/#review67620

(I'm not sure why I got another r?, but the code still looks good to me, so hopefully this will change that to an r+.  ;)

Comment 31

[Kris Maglione [:kmag]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9999b6b8022bfe815d79a4f309986d2859285e16
Bug 1280128: [webext] Use transparent backgrounds and correct border radii for popup browsers. r=bwinton ui-r=maritz

Comment 32

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

I had to back this out in https://hg.mozilla.org/integration/mozilla-inbound/rev/9a6840ba62cd for eslint failures.

https://treeherder.mozilla.org/logviewer.html#?job_id=33580931&repo=mozilla-inbound

Comment 33

[Kris Maglione [:kmag]]

Oops. Rebase botch...

Comment 34

[Kris Maglione [:kmag]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d7750d91b9179fab6fe27f912552101d2515c5b9
Bug 1280128: [webext] Use transparent backgrounds and correct border radii for popup browsers. r=bwinton ui-r=maritz

Comment 35

[Kris Maglione [:kmag]]

Comment on attachment 8773124 [details]
Bug 1280128: [webext] Use transparent backgrounds and padding for popup browsers.  ui-r?maritz

Approval Request Comment
[Feature/regressing bug #]: Bug 1225633
[User impact if declined]: This issue creates a serious visual defect on the most common versions of Windows and Linux, which makes our implementation appear non-production-quality. Per comment 2, this is likely to deter serious developers from investing in their Firefox add-ons.
[Describe test coverage new/current, TreeHerder]: This patch adds tests to make sure that the styling of the panels matches what is expected for every platform we test on, and that this and related visual glitches do not occur. There is also fairly comprehensive existing test coverage for the layout and appearance of the panels that this affects.
[Risks and why]: Low. The changes are mostly limited to CSS, and the addition of a single attribute to a <browser> node. The only potentially risky change is the injection of an additional stylesheet into the content page loaded into this popup, which I think should be uplifted to Aurora, but not to Beta.
[String/UUID change made/needed]: None.

Comment 36

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/d7750d91b917

Comment 37

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8773124 [details]
Bug 1280128: [webext] Use transparent backgrounds and padding for popup browsers.  ui-r?maritz

Recent regression (from 48), let's fix this for 49. 
This should make it into beta 4 next week.

Comment 38

[Liz Henry (:lizzard) (relman/hg->git project)]

Kris, can you help outline how QA can test this ? I see you have included some tests, but manual testing seems like a good idea here too.

Comment 39

[Jared Wein [:jaws] (please needinfo? me)]

This patch uses margin-right: -1px; but that will most likely not work as you intended for RTL users. This should be replaced with margin-inline-end: -1px;

Comment 40

[Kris Maglione [:kmag]]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #39)
> This patch uses margin-right: -1px; but that will most likely not work as
> you intended for RTL users. This should be replaced with margin-inline-end:
> -1px;

I tested, and that does seem to be the case.

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #38)
> Kris, can you help outline how QA can test this ? I see you have included
> some tests, but manual testing seems like a good idea here too.

1) Create a WebExtension with a browserAction and a pageAction popup, both
with opaque backgrounds.

2) With the browserAction button in the toolbar, open the popup and check that
the background extends to the entire visible area of the popup, excluding the
arrow. Also check for the following OS-specific behavior:

 - Windows 7 and below: The popup should have rounded corners with a 4px
 radius.

 - Windows 8 and above: The popup should have square corners, and the
 background color should extend all the way to each corner, without clipping.

 - Linux: The popup should have square corners, and the
 background color should extend all the way to each corner, without clipping.

 - Windows 7 and below: The popup should have rounded corners with a 3.5px
 radius.

3) Do the same for the pageAction button in the urlbar.

4) Move the browserAction into the menu (by right clicking the toolbar button
and selecting "Move to Menu"). Open the menu and click the browserAction
button. Check that the background color of the popup content is not clipped at
the corners. Exactly how far the background color extends will vary by Firefox
version, so all that's important here is that we don't have unexpected
clipping of the corners.

Comment 41

[Kris Maglione [:kmag]]

(In reply to Kris Maglione [:kmag] from comment #40)
> (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #39)
> > This patch uses margin-right: -1px; but that will most likely not work as
> > you intended for RTL users. This should be replaced with margin-inline-end:
> > -1px;
> 
> I tested, and that does seem to be the case.

Actually, it looks like something changed to make this negative margin no
longer necessary, so I'll just remove it.

Comment 42

[Kris Maglione [:kmag]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/14c2310b7782e1aef73b483a9462e4cf1497c3d1
Bug 1280128: Follow-up: Remove unnecessary negative margin. r=me

Comment 43

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/14c2310b7782

Comment 44

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Does this need the followup folded in before we uplift?

Comment 45

[Kris Maglione [:kmag]]

(In reply to Wes Kocher (:KWierso) from comment #44)
> Does this need the followup folded in before we uplift?

For aurora, yes. I'm going to provide a separate, slightly pared-down patch for beta.

Comment 46

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/61161615e987

Comment 47

[Kris Maglione [:kmag]]

Attachment: popup-corners-beta.diff

Patch grafted onto beta, and with the popup CSS injection changes removed.

Comment 48

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/a507b6cde54b

Comment 49

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/a7ef4e7277b4

Comment 50

[Ryan VanderMeulen [:RyanVM]]

Backed out from Beta for browser_ext_popup_corners.js failures.
https://hg.mozilla.org/releases/mozilla-beta/rev/91505c2a68fb

Comment 51

[Ryan VanderMeulen [:RyanVM]]

Was failing on WinXP, Win7, and OSX 10.10.

Comment 52

[Kris Maglione [:kmag]]

Re-landed after adding a missing class to the browser element: https://hg.mozilla.org/releases/mozilla-beta/rev/528631e448f2

Comment 53

[Andrei Vaida [:avaida]]

I've managed to reproduce this bug on 48.0.2-build1 (20160823121617),
using Windows 10 x64.

I've created a very basic WebExtension based on your instructions
(Comment 40) and I've noticed the following results:

    Windows 10 x64
        - 51.0a1 (2016-04-25): the background extends to the entire
          visible area, *including* the arrow, for both the
          browserAction and pageAction popups
           — 

Comment 54

[Andrei Vaida [:avaida]]

(Agh, must've hit the save button too soon. Here's what I was trying to say in Comment 53.)

I've managed to reproduce this bug on 48.0.2-build1 (20160823121617),
using Windows 10 x64.

I've created a very basic WebExtension based on your instructions
(Comment 40) and I've noticed the following results:

    Windows 10 x64
        - 51.0a1 (2016-04-25): the background extends to the entire
          visible area, *including* the arrow, for both the
          browserAction and pageAction popups
           - screenshot: http://imgur.com/a/ypA09

        - 50.0a2 (2016-04-25): the background extends to the entire
          visible area, *excluding* the arrow AND there's a white
          right-border visible, for both the browserAction and
          pageAction popups
           - screenshot: http://imgur.com/a/pQkyf

        - 49.0b6-build1 (20160822111414): the background extends to
          the entire visible area, *excluding* the arrow, for both
          the browserAction and pageAction popups
           - screenshot: http://imgur.com/a/9BzG9


    Windows 8.1 x86
        - 51.0a1 (2016-04-25): the background extends to the entire
          visible area, *including* the arrow, for both the
          browserAction and pageAction popups
           - screenshot: http://imgur.com/a/bNLTX

        - 50.0a2 (2016-04-25): the background extends to the entire
          visible area, *excluding* the arrow AND white borders are
          also visible, for both the browserAction and pageAction
          popups
           - screenshot: http://imgur.com/a/nEx6A

        - 49.0b7-build1 (20160825132718): the background extends to
          the entire visible area, *excluding* the arrow, for both
          the browserAction and pageAction popups
           - screenshot: http://imgur.com/a/CSnx3

   Windows 7 x64
        - 51.0a1 (2016-04-25): the background extends to the entire
          visible area, *including* the arrow, for both the
          browserAction and pageAction popups
           - screenshot: http://i.imgur.com/0Cl9wlq.png
           - note: couldn't confirm the border-radius

        - 50.0a2 (2016-04-25): the background extends to the entire
          visible area, *excluding* the arrow AND white borders are
          also visible, for both the browserAction and pageAction
          popups
            - screenshot: http://i.imgur.com/Wi8gc9x.png
            - note: couldn't confirm the border-radius

        - 49.0b7-build1 (20160825132718): the background extends to
          the entire visible area, *excluding* the arrow, for both
          the browserAction and pageAction popups
           - screenshot: http://i.imgur.com/kc4ZOa3.png
           - note: couldn't confirm the border-radius


    Windows XP SP2 x64
        - 51.0a1 (2016-04-25): the background extends to the entire
          visible area, *including* the arrow, for both the
          browserAction and pageAction popups
           - screenshot: http://imgur.com/a/89KRn
           - note: couldn't confirm the border-radius

        - 50.0a2 (2016-04-25): the background extends to the entire
          visible area, *excluding* the arrow AND white borders are
          also visible, for both the browserAction and pageAction
          popups
           - screenshot: http://imgur.com/a/f07sL
           - note: couldn't confirm the border-radius

        - 49.0b7-build1 (20160825132718): the background extends to
          the entire visible area, *excluding* the arrow, for both
          the browserAction and pageAction popups
           - screenshot: http://imgur.com/a/c3SZu
           - note: couldn't confirm the border-radius


    Ubuntu 14.04 x86
        - 51.0a1 (2016-04-25): the background extends to the entire
          visible area, *including* the arrow, for both the
          browserAction and pageAction popups
           - screenshot: http://imgur.com/a/eWufw

        - 50.0a2 (2016-04-25): the background extends to the entire
          visible area, *excluding* the arrow, for both the
          browserAction and pageAction popups
           - screenshot: http://imgur.com/a/zzBn4

        - 49.0b7-build1 (20160825132718): the background extends to
          the entire visible area, *excluding* the arrow, for both
          the browserAction and pageAction popups
           - screenshot: http://imgur.com/a/hR41v


 I suspect the borders I mentioned for 50.0a2 and 49.0b (Windows XP
 SP2 x64, Windows 7 x64,Windows 8.1 x86) are expected, as they might
 be part of the default popup styling -- note that I didn't specify
 any kind of border styling in my WebExtension.

 I'm also not sure how the background should work while the
 WebExtension is placed inside the menu. Here's what it looks like
 on Nightly, Windows 10 x64: http://imgur.com/a/YbnMU.

 Kris, what's your opinion on these?

Comment 55

[Kris Maglione [:kmag]]

(In reply to Andrei Vaida, QA [:avaida] – please ni? me from comment #54)
>         - 50.0a2 (2016-04-25): the background extends to the entire
>           visible area, *excluding* the arrow AND there's a white
>           right-border visible, for both the browserAction and
>           pageAction popups
>            - screenshot: http://imgur.com/a/pQkyf

Hm. I guess we'll have to re-add the negative end margin for 50, but not 49 or
51. I'll look into this a bit more and try to find out exactly what's going
on.

>  I'm also not sure how the background should work while the
>  WebExtension is placed inside the menu. Here's what it looks like
>  on Nightly, Windows 10 x64: http://imgur.com/a/YbnMU.

That's the expected appearance, but it will vary across versions, since we
size the browser in the menu panel differently in nightlies than in previous
versions.

These changes shouldn't really affect the menu panel, though, so there
probably isn't any point in specifically testing it.

Comment 56

[Kris Maglione [:kmag]]

(In reply to Kris Maglione [:kmag] from comment #55)
> (In reply to Andrei Vaida, QA [:avaida] – please ni? me from comment #54)
> >         - 50.0a2 (2016-04-25): the background extends to the entire
> >           visible area, *excluding* the arrow AND there's a white
> >           right-border visible, for both the browserAction and
> >           pageAction popups
> >            - screenshot: http://imgur.com/a/pQkyf
> 
> Hm. I guess we'll have to re-add the negative end margin for 50, but not 49
> or
> 51. I'll look into this a bit more and try to find out exactly what's going
> on.

Ok, apparently this is being caused by the extra 1px that we add to the calculated width of the browser, combined with a layout bug caused by the size calculation code reflowing the browser to its preferred width. I don't know why we're only seeing this on 50 now, I'm considering removing the extra 1px and uplifting to 50, since this bug seems worse, and more common, than the one rhat was trying to address[1].

Thoughts?

[1]: Sometimes lines of text wind up wrapping, even though the panel should be wide enough for them. I can't actually reproduce this anymore, and it's possible that ot was fixed by recent changes to the resizing code that hid the panel's scrollbars.

Comment 57

[Blake Winton (:bwinton) (:☕️)]

If we remove it, would that only be for 50, and if not, would it cause scrollbars in 49 and 51?
(I think I'm okay with the removing it and uplifting.  If lines of text wrap, the author has the option of adding an extra pixel themselves…)

Comment 58

[Kris Maglione [:kmag]]

(In reply to Blake Winton (:bwinton) (:☕️) from comment #57)
> If we remove it, would that only be for 50, and if not, would it cause
> scrollbars in 49 and 51?
> (I think I'm okay with the removing it and uplifting.  If lines of text
> wrap, the author has the option of adding an extra pixel themselves…)

I think we should remove it for 50+. The 1px gap issue doesn't seem to be affecting 49.

There shouldn't be any issues with scrollbars. The initial issue was that the last word of a line of text would wrap sometimes, unless we added the extra pixel. I suspect the problem had to do with the panel's scrollbar briefly appearing while we were resizing (which isn't an issue anymore), but I can't say for sure.

Comment 59

[Liz Henry (:lizzard) (relman/hg->git project)]

OK, shall we call this "affected" for 50 then?  But not for 51?

Comment 60

[Kris Maglione [:kmag]]

I'm going to file a follow-up bug for the 1px border issue, since it's technically unrelated to the corner clipping issue this bug was filed for.