Closed Bug 1759089 Opened 3 years ago Closed 2 years ago

bookmark manager menu items hard to target

Categories

(Core :: Graphics, defect)

Firefox 98
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: skyhook, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

  • Application Menu/Bookmarks/Manage bookmarks
  • pop-up window "Library" appears
  • select menu header "Organize", "Views", or "Import and Backup"
  • menu should pull down for further selections

Actual results:

Response to menu selection is intermittent and flaky. Frequently behaves as If trying to window drag and will display grab cursor every time if purposely held. If not held, frequently will quickly flash pulldown menu and grab cursor.

After experimenting it seems two things are evident:

  1. There are two different behaviours up top; if I drag by the title bar, the grab cursor replaces the arrow cursor only when the window starts to move. If I drag on any part of the menu headers or open space beside, the grab cursor appears on mousedown, which is very difficult to perform without actually moving the window. To elaborate, I can click and hold in the title bar all day and not actually move the window, but it's extremely challenging to click in the menu area without moving the window. When the pulldown works, the window hasn't moved. I don't know why I would want to window drag using a menu header as a target, so this feels wrong. A successful menu pulldown becomes a window drag if the mousedown is held. That also feels inappropriate as I intuitively expect it to ignore the window until after I mouseup a menu item or move my cursor off the menu. FF main menus behave in this manner as I would expect.

  2. Most failed pulldown selections, but not all, are accompanied by window movement as if the window has decided dragging is happening I do not have trouble with mouse actions in general and can only report that this happens.

It's very hard to reliably select that window menu items, usually takes a few attempts. Has been like this several revs but I ignored it imagining it was user error. I have a new mouse now and it seems not, and I promised myself I'd speak up if v98 showed no improvement.

Expected results:

When pulling down a menu does work, intermittently, it pulls down on a single click then hovering allows item selection with a second click. I imagine this is the intention, but I would expect it also to work by dragging the mousedown and releasing on a menu choice. Again, this describes the main window menu behaviour.

The Bugbug bot thinks this bug should belong to the 'Firefox::Bookmarks & History' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Bookmarks & History

Please can you try running Firefox with this environment variable set: MOZ_ENABLE_WAYLAND=0 ?

This feels like it might be related to bug 1761877.

Flags: needinfo?(skyhook)

(In reply to Mark Banner (:standard8) from comment #2)

Please can you try running Firefox with this environment variable set: MOZ_ENABLE_WAYLAND=0 ?
This feels like it might be related to bug 1761877.

  • requested variable set
  • reboot
  • relaunch
    Bad behaviour unchanged.
Flags: needinfo?(skyhook)

Should have added now running FF v98.0.2 (64-bit) Linux.

The severity field is not set for this bug.
:mak, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mak)

Now running FF v99.0; Manage Bookmarks works fine now, like a repair with volition:

  • menus pull down and stay down on a select
  • alternate menus pull down in the same state if moving the cursor
  • hover pops up submenus and remain in that state
  • no stuttering or aiming issues, one click = one event
  • hover marquees focus on unselected menus
  • window drag is restricted to the title bar and blank area menu bar

I can't get it to misbehave even when trying to freak it out; it has absolutely calmed down like a repair. Unrelated to function, I find it odd that the window is titled "library" and the empty menu bar can be dragged, but obviously a decision was made there. I also have some odd video artifacts that intermittently appear when using this window, but they occasionally appear elsewhere in FF and are of little concern so I've never tried to establish it as a problem. Should I mention a video artifact that only happens in FF?

1761877 and 1763464 are both mentioned but still open. Just for thrills, I toggled MOZ_ENABLE_WAYLAND=0 false in "about:config" (if that works) and Manage Bookmarks remained working perfectly. Is there any opinion on which way I should leave that variable in the long run, or if I should delete it from config in a preferred state to avoid future problems?

(In reply to Optional from comment #6)

Just for thrills, I toggled MOZ_ENABLE_WAYLAND=0 false in "about:config" (if that works)

Sorry, I'm confused, MOZ_ENABLE_WAYLAND is an ENV variable that should be set before launching Firefox, it has nothing to do with about:config

How you should set it depends on the problems it solves.

Flags: needinfo?(mak) → needinfo?(skyhook)

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

(In reply to Optional from comment #6)

Just for thrills, I toggled MOZ_ENABLE_WAYLAND=0 false in "about:config" (if that works)
Sorry, I'm confused, MOZ_ENABLE_WAYLAND is an ENV variable that should be set before launching Firefox, it has nothing to do with about:config
How you should set it depends on the problems it solves.

Judging by the way the interface works, and my own ineptitude, I think you can ignore my first question because it appears I created "MOZ_ENABLE_WAYLAND" by typing it as a search term, then selecting the plus button assuming I was selecting a boolean toggle, you know, plus one. I just deleted it.

About the problem the environmental varialbe solves; I toggled it in the terminal as requested and it did nothing I could discern. I'd like to know what might be the most logical way to leave it set in the long run. Did I create the environmental variable by setting its state when it didn't even exist before? It's my understanding that FF uses X11 by default, I report X11 in about:support, and I report X11 as $XDG_SESSION_TYPE, so I'm just admitting I don't understand and have never seen any application demand Wayland, or know what that might look like if I don't have it installed. Everything I've checked so far seems to indicate I don't have Wayland, but everything I read feels like it should be there as a current standard.

Flags: needinfo?(skyhook)

Moving across to core, as this feels something specific to menu handling.

Component: Bookmarks & History → Graphics
Product: Firefox → Core

Now running FF v100.0; Manage Bookmarks still works fine now, like a repair with volition.

The severity field is not set for this bug.
:bhood, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(bhood)

Hi! Your latest comment appears to indicate that this behavior no longer exists in current builds. If that is indeed the case, please consider closing out this report.

Severity: -- → S4
Flags: needinfo?(bhood) → needinfo?(skyhook)

(In reply to Bob Hood from comment #12)

Hi! Your latest comment appears to indicate that this behavior no longer exists in current builds. If that is indeed the case, please consider closing out this report.

If you wish, but I didn't find any FAQ on how to close a bug report, interface for that, or indication that I'm allowed to.
I selected "resolved" status, four sheets to the wind.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID

This will remain invalid forever without feedback on how I'm supposed to close it, assuming closing without understanding is the goal.

Flags: needinfo?(skyhook)
You need to log in before you can comment on or make changes to this bug.