https://bugs.documentfoundation.org/show_bug.cgi?id=158031

Justin L <jl...@mail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.documentfounda
                   |                            |tion.org/show_bug.cgi?id=13
                   |                            |7445

--- Comment #1 from Justin L <jl...@mail.com> ---
The reason the "Edit Hyperlink" is available is because there was a hyperlink
underneath the mouse cursor.
(editeng/source/misc/urlfieldhelper.cxx URLFieldHelper::IsCursorAtURLField)

The right-click MOVES the cursor - either before the hyperlink (the first half)
or after the hyperlink (the second half).

Caolan indicated that =gen tracks the mouse position at the point of the menu
OPENING, while =gtk3 tracks the current mouse position as the menu is
DISMISSED.

The problem is with the mouse moving away from the "target area" and pressing
"Edit Hyperlink" in the menu. Now when it checks to verify that the command is
allowed to run, the hyperlink is no longer underneath the mouse of course,
because the mouse has moved into the menu!! Over the right half, the cursor
position doesn't have field in it's "non-selection" position either, so
GetState marked the slot as invalid and the command was simply not permitted to
run.

Possibly the solution is just to make it a fastcall, so that it does not verify
whether it is allowed to execute the slot. The fact that the slot was available
in a menu should be enough...

SfxVoidItem EditHyperlink SID_EDIT_HYPERLINK
    FastCall = TRUE,

This works because all of the SID_EDIT_HYPERLINKs do a
pOLV->SelectFieldAtCursor() which explicitly selects backwards if necessary.

SD doesn't have the mouse-moved-to-menu-position problem because of
tdf#137445's https://gerrit.libreoffice.org/c/core/+/117653 which seems
over-elaborate.

Alternatively, we could change the GetFieldAt...() to look for a field before
the "non-selection" position.

-----
Relating to side note - that was a wild goose chase. If the cursor is AFTER the
hyperlink, Insert - Hyperlink ALWAYS starts a new one - true for native URLs in
all apps as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to