1070922 - buttons on (default browser) notification bar are not visible/cropped when the window is made narrower (width reduced)

Status: RESOLVED WORKSFORME

(Toolkit :: UI Widgets, defect)

Description

[Cornel Ionce [:noni] [Hubs QA]]

Attachment: options_not_visible_in_minimum_width.jpg

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:35.0) Gecko/20100101 Firefox/35.0
Mozilla/5.0 (X11; Linux i686; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20140921030208

STR:
1. Open Firefox using a clean profile.
2. Resize the window until minimum width.

Actual Results:
The buttons from the Default browser prompt are cropped while the browser is resized.
When the browser it's at minimum width, only one button is displayed, the second one is barely visible.

Expected Results:
The buttons (including the X <<close>> one) must be visible.

Notes:
This issue also reproduces on Latest Aurora 34.0a2, build ID: 20140921004003.

Comment 1

[Raluca Popovici, Desktop QA]

I will reopen this bug because is still reproducible even if The Default Browser prompt was updated, the buttons are not visible on minimum witdh and cannot scroll to reach them. Reproduced on Win 10x64 using latest Nightly 126.0a1.

Comment 2

[Raluca Popovici, Desktop QA]

Attachment: image_2024_03_28T11_31_21_100Z.png

Comment 3

[:Gijs (he/him)]

The recent screenshot you added is for a modal, not a notification bar, and is limiting the height of the browser window rather than the width. I suspect that issue would be better off as a new bug. WRT that bug, it would be good to clarify if you resized the browser window after the dialog showed up or before? Does it make a difference to the outcome?

For the notification bar that was the subject of this original bug, it looks like this was moved in bug 1656494 and is now in https://searchfox.org/mozilla-central/rev/159929cd10b8fba135c72a497d815ab2dd5a521c/browser/components/asrouter/modules/CFRMessageProvider.sys.mjs#773-791 . I don't know how to test triggering that, or if that message and CFR is in active use, or if it could be removed from the code. Shane?

Comment 4

[Shane Hughes [:aminomancer]]

(In reply to :Gijs (he/him) from comment #3)

The recent screenshot you added is for a modal, not a notification bar, and is limiting the height of the browser window rather than the width. I suspect that issue would be better off as a new bug. WRT that bug, it would be good to clarify if you resized the browser window after the dialog showed up or before? Does it make a difference to the outcome?

For the notification bar that was the subject of this original bug, it looks like this was moved in bug 1656494 and is now in https://searchfox.org/mozilla-central/rev/159929cd10b8fba135c72a497d815ab2dd5a521c/browser/components/asrouter/modules/CFRMessageProvider.sys.mjs#773-791 . I don't know how to test triggering that, or if that message and CFR is in active use, or if it could be removed from the code. Shane?

That's a different message, actually a no-op archive of a message. The targeting: "false" negates it. The message in the screenshot is the DefaultBrowserCheck prompt (see strings here). OMC doesn't currently control it, but we have been considering taking it over and converting it to our messaging system (bug 1825381).

To test it, there are several checks that need to be passed. The main reason we don't see it much is there's a RELEASE_OR_BETA check. (Is there a way to override that constant for a local build? That would sure be nice.) Anyway, here are some steps:

1. OS = Windows
2. release build
3. build is not set to default browser
4. make a new profile, and set it to default profile
5. run it
6. restart firefox
7. it should show the prompt up to 3 times, but you can reset it with browser.shell.defaultBrowserCheckCount

Comment 5

[:Gijs (he/him)]

(In reply to Shane Hughes [:aminomancer] from comment #4)

(In reply to :Gijs (he/him) from comment #3)

The recent screenshot you added is for a modal, not a notification bar, and is limiting the height of the browser window rather than the width. I suspect that issue would be better off as a new bug. WRT that bug, it would be good to clarify if you resized the browser window after the dialog showed up or before? Does it make a difference to the outcome?

For the notification bar that was the subject of this original bug, it looks like this was moved in bug 1656494 and is now in https://searchfox.org/mozilla-central/rev/159929cd10b8fba135c72a497d815ab2dd5a521c/browser/components/asrouter/modules/CFRMessageProvider.sys.mjs#773-791 . I don't know how to test triggering that, or if that message and CFR is in active use, or if it could be removed from the code. Shane?

That's a different message, actually a no-op archive of a message. The targeting: "false" negates it. The message in the screenshot is the DefaultBrowserCheck prompt

I don't care about the message/dialog in the more recent screenshot, only about the message bar that bug 1656494 changed to use the messaging system. See also comment 0 and the original screenshot (notification bar, not a dialog).

Comment 6

[Shane Hughes [:aminomancer]]

Attachment: infobar with tiny window

I see. There is a similar infobar on Remote Settings, which we are also considering removing in bug 1825377. Firefox fetches some messages from RS, and the relevant one is INFOBAR_DEFAULT_AND_PIN_87. Targeting is quite restrictive:

1. triggers on startup
2. Fx is not default browser
3. browser.shell.checkDefaultBrowser is set to false
4. OS is not linux
5. profile is between 5 and 15 weeks old

It's probably easier to just change the targeting. You can do that like this:

1. Open OnboardingMessageProvider
2. Add the following message (it has more permissive targeting) to the BASE_MESSAGES array (line 62):

   {
     groups: ["cfr"],
     content: {
       text: { string_id: "default-browser-notification-message" },
       type: "global",
       buttons: [
         {
           label: { string_id: "default-browser-notification-button" },
           action: { type: "PIN_AND_DEFAULT" },
           primary: true,
           accessKey: "P",
         },
       ],
       category: "cfrFeatures",
       bucket_id: "INFOBAR_DEFAULT_AND_PIN_87",
     },
     trigger: { id: "defaultBrowserCheck" },
     template: "infobar",
     targeting:
       "!activeNotifications && !willShowDefaultPrompt && source == 'startup'",
     id: "INFOBAR_DEFAULT_AND_PIN_87",
   },
   

3. Launch firefox, it should show on startup

The InfoBar messaging surface is just a wrapper for notificationbox. So I think this could theoretically impact any notificationbox, as long as the notificationbox shows up after the window is already small, rather than trying to shrink the window while a notificationbox is already open. If you shrink the window while it's already open, the entire notificationbox ends up outside the window bounds. Whereas if you start with a tiny window, at least on Windows 10, the title is visible but not the buttons.

I took the attached screenshot via some extra steps. After launching Firefox for the first time on a new profile, the infobar immediately showed (as the targeting here is more permissive). But that's fine since I removed the frequency caps from this version too, so it can show on every startup. So I dismissed the infobar and resized the window to the smallest dimensions possible. Then I restarted Firefox, with session restore enabled. On the next launch, the window started with the persisted tiny dimensions, and the infobar showed up like this.

Comment 7

[:Gijs (he/him)]

Thanks! Let's move this to reusable widgets then, clearing severity (as it affects more notification bars) and we can consider what if anything we want to do about it.

Raluca: it would still be useful to get a separate bug on file for the modal dialog/prompt we now use to ask about default browser and how it doesn't work well when reducing window height. Leaving needinfo for that.

Comment 8

[Raluca Popovici, Desktop QA]

I managed to file a new bug for this: https://bugzilla.mozilla.org/show_bug.cgi?id=1889329

Comment 9

[Hanna Jones [:hjones]]

Thanks for digging into this! I'm going to close this out in favour of Bug 1889433 - it seems like setting a larger minimum height on our browser window would potentially fix a number of issues, including Bug 1889329.

Closing as WORKSFORME since the width isn't an issue anymore.

Comment 10

[:Gijs (he/him)]

(In reply to Hanna Jones [:hjones] from comment #9)

Thanks for digging into this! I'm going to close this out in favour of Bug 1889433 - it seems like setting a larger minimum height on our browser window would potentially fix a number of issues, including Bug 1889329.

Closing as WORKSFORME since the width isn't an issue anymore.

Confusingly, I think the issues with the notification bar (cf. comment 0 / comment 6) are more to do with the minimum width than the minimum height, and so I don't think that fixing bug 1889433 would address them.

Comment 11

[Hanna Jones [:hjones]]

Attachment: Browser containing infobar reduced to minimum width and height vs minimum width but slightly expanded height

(In reply to :Gijs (he/him) from comment #10)

(In reply to Hanna Jones [:hjones] from comment #9)

Thanks for digging into this! I'm going to close this out in favour of Bug 1889433 - it seems like setting a larger minimum height on our browser window would potentially fix a number of issues, including Bug 1889329.

Closing as WORKSFORME since the width isn't an issue anymore.

Confusingly, I think the issues with the notification bar (cf. comment 0 / comment 6) are more to do with the minimum width than the minimum height, and so I don't think that fixing bug 1889433 would address them.

Apologies I should have expanded on the thinking behind that comment.

The original bug/comment was about notification bar buttons getting cut of when the browser is too narrow. Strictly speaking this no longer happens - when the browser window is narrow buttons in notification bars flow to a new line, which is the expected/desired behaviour. If both the browser width and height are reduced to their minimum possible dimensions though, it may appear that buttons are still getting cut off because it's not possible to scroll the browser chrome to see the full message in the notification bar. I believe this is what was happening in comment 6. To me that seems to be an issue stemming from the fact that the minimum height of Firefox is so small, which is why I filed bug 1889433 as a follow up.

I've attached a screenshot with an example of a notification bar with the button wrapped to a new line to show that it becomes visible once you expand the height of the browser window. Hopefully that clarifies things a bit!

Comment 12

[Hanna Jones [:hjones]]

If anyone is curious to test for themselves you can trigger the notification in my screenshot by entering this in your browser toolbox:

BrowserSearch.removalOfSearchEngineNotificationBox("Google", "Foogle")