1876558 - Tab preview still displayed when focusing the URL bar using keyboard shortcut covering the search entry

Status: NEW

(Firefox :: Tabbed Browser, defect, P2)

Description

[Bogdan Maris, Desktop QA]

Attachment: Gif showing the issue

Found in

• Latest Nightly 124.0a1 (2024-01-25)

Affected versions

• Latest Nightly 124.0a1 (2024-01-25)

Tested platforms

• Affected platforms: Windows 11, macOS 13.6 and Ubuntu 22.04

Preconditions

• Activate the feature by setting browser.tabs.cardPreview.enabled as true in about:config

Steps to reproduce

1. Open a few websites in different tabs
2. Hover over the first or second tab
3. Press ctrl/cmd+L and write something in the URL bar

Expected result

• Tab hover preview is closed in order to focus on the URL bar

Actual result

• The preview is covering the URL bar.

Regression range

• Not a regression since this is reproducible on old Nightly build from 2024-01-13 where this feature officially landed.

Additional notes

• With the feature being off this is still an issue but of course not nearly as intrusive as with the feature on.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:bmaris, if you think that's a regression, could you try to find a regression range using for example mozregression?

Comment 2

[Jeremy Swinarton]

I discussed a few possible options with [e-mail] to address this. My opinion is that the best option is to close the tab preview panel when any key is pressed, but allow it to operate normally if the URL bar is already open when the tab is hovered over. (This appears to be how Chrome implements it.)

The other option considered was to disable the tab preview at any point when the URL bar is focused. I think this could create confusion, as a user could reasonably expect tab preview to work when the URL bar is open. For example, if they are halfway through typing something into the URL bar and then move their mouse to hover over a tab. In this case I think the reasonable expectation would be for the tab preview to open over top of the URL bar.

Comment 3

[Marco Bonardo [:mak]]

is tab preview a menupopup/panel today? I'm asking because the same bug affects the downloads panel, or the main menu panel, focusing the urlbar with the keyboard shortcut should close other panels but it currently doesn't because it's not a popup.
Then I suspect this is Bug 1626741, where Neil suggested we invoke nsPopupManager::Rollup() when the address bar panel opens.

Comment 4

[Jeremy Swinarton]

Yes, the tab preview is implemented as a panel.

However, I notice that bug1626741 is several years old and is marked as P3. This one, however, was identified as a blocker to the launch of tab preview on the release channel. Is there a plan to address this soon? If there is not, I think it makes sense for us to address this separately by listening for key presses as I mentioned above, and revisit once the other bug has been addressed.

Comment 5

[Chris Peterson [:cpeterson]]

This bug is a THP release blocker.

Comment 6

[Marco Bonardo [:mak]]

(In reply to Jeremy Swinarton from comment #4)

However, I notice that bug1626741 is several years old and is marked as P3. This one, however, was identified as a blocker to the launch of tab preview on the release channel. Is there a plan to address this soon? If there is not, I think it makes sense for us to address this separately by listening for key presses as I mentioned above, and revisit once the other bug has been addressed.

The priority of this bug is not necessarily a reason to ignore a better fix. What's the deadline to release tab previews? Is there enough time to try to implement the more general fix, like the one Neil suggested in bug 1626741?
Bug 1626741 is a P3 just because so far there was no strong reason to fix it sooner, this bug could be that reason.
I'd suggest to at least try investigating the better fix, in the worst case it will be ok to land a workaround and have a bug on file to remove it once the right fix will be available. If you can provide timing, that'd help.

Comment 7

[Jeremy Swinarton]

(In reply to Marco Bonardo [:mak] from comment #6)

(In reply to Jeremy Swinarton from comment #4)

However, I notice that bug1626741 is several years old and is marked as P3. This one, however, was identified as a blocker to the launch of tab preview on the release channel. Is there a plan to address this soon? If there is not, I think it makes sense for us to address this separately by listening for key presses as I mentioned above, and revisit once the other bug has been addressed.

The priority of this bug is not necessarily a reason to ignore a better fix. What's the deadline to release tab previews? Is there enough time to try to implement the more general fix, like the one Neil suggested in bug 1626741?
Bug 1626741 is a P3 just because so far there was no strong reason to fix it sooner, this bug could be that reason.
I'd suggest to at least try investigating the better fix, in the worst case it will be ok to land a workaround and have a bug on file to remove it once the right fix will be available. If you can provide timing, that'd help.

I agree with this. We are aiming to land this in 128.

Comment 8

[Marco Bonardo [:mak]]

I'm posting a wip patch to bug 1626741. Unfortunately my time for today is way off, it will need more testing to ensure it's not breaking stuff, but it seems to do the job.