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.

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

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.

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.

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. ;)

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

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.

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 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.

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.

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.

(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.

(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?

(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.

(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?

(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.

(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?

(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.

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 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 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 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 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).

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.

Okay, that sounds close enough for me. :)

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.

(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 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 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 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+. ;)

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

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

Oops. Rebase botch...

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 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 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.

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.

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;

(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.

(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.

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

Does this need the followup folded in before we uplift?

(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.

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

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

Was failing on WinXP, Win7, and OSX 10.10.

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

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 —

(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?

(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.

(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.

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…)

(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.

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

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.