Issue 63188

Summary: OOo 1.1-like right-click behaviour should be an available option
Product: General Reporter: petrushka <peter_gainsford>
Component: uiAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: issues, lars_o_hansen
Version: OOo 2.0.2Keywords: oooqa
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Latest Confirmation in: ---
Developer Difficulty: ---

Description petrushka 2006-03-15 00:41:48 UTC
In the transition from OOo 1.1.x to OOo 2.x, the effect of right-clicking in a
window changed. In OOo 1.1, right-clicking did not change the selection or
cursor position, so it was possible to right-click anywhere in the window to get
a context menu for wherever the cursor or selection was; in OOo 2,
right-clicking moves the cursor and/or selection.

This change was in response to issue 20330, issue 6413, issue 9698, and probably
others that I haven't found. (In the case of issue 9698, an argument was put
forward in favour of the new behaviour: in 1.1, getting the context menu for a
hyperlink required the user first to move the cursor into the hyperlink by using
the keyboard, and only then right-clicking.)

The new behaviour causes problems too. The actual reason for the change, it
seems to me, is that the new behaviour is modelled on Microsoft Office.

To balance this, I'd like to offer the following reasons for this enhancement

(1) There are plenty of applications out there whose right-click behaviour is
like OOo 1.1: e.g. Firefox, Thunderbird, jEdit, to name just the three I happen
to have running at the moment. 1.1-like right-click behaviour was probably not
actually more common than the new behaviour, but it was certainly fairly standard.

(2) With the new behaviour it takes extra time to aim the mouse accurately
before right-clicking. Sometimes this can be quite difficult (e.g. when trying
to get the context menu for a transparent text box with no borders), but always
it involves an extra five seconds or so of precision aiming. Over the course of
a day, this can lead to a substantial drop in productivity.

(3) In addition, many people prefer to use a keyboard, rather than a mouse, as
their main means of interacting with a computer, especially when doing typing
work. For such people (especially when using Writer), having to switch to a
mouse for several seconds of precision aiming is a significant interruption and
potentially even a distraction.

Considering how much opinion is likely to vary on something like this, I suggest
making 1.1-like behaviour and 2.0-like right-click behaviour an option.

As an alternative, I suggest adding a new keyboard combination to access context
menus (some, but not all, keyboards have a dedicated "context menu" key). In
view of the 3rd point I raise above, this might even be deemed to be the best
solution overall.

(I previously raised this topic on, at
Comment 1 lars 2006-03-15 17:14:57 UTC
according to
RFE_issues_by_QA.sxd I reassign this issue to requirements and set the status 
to New
Comment 2 richlv 2006-05-22 11:00:33 UTC
i'd like to add my support for this.
the new behaviour seems unfriendly to me (even though i saw the issues leading 
to this change), also several longtime users have complained to me about 
this change.

the biggest problem, as i see it, was not acting upon target right click 
area when there is no selection - wouldn't the best solution be to keep the old 
behaviour when having a selection and movin the cursor when there is no 
selection ?

nevertheless, i would like to see a solution for this change, be it a 
compromise change or an option.