Bug 46108 - Erratic menu behaviour
Summary: Erratic menu behaviour
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version: 3.5.0 release
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-15 07:06 UTC by Owen Savill
Modified: 2015-01-05 17:52 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Wrong placement of long menu (1.98 MB, image/png)
2012-03-29 03:45 UTC, daniel
Details

Description Owen Savill 2012-02-15 07:06:56 UTC
I assume this is partly deliberate but it executes poorly on my system.

The menus switch direction, presumably to try and avoid the menu content from being lost of the edge of the display. However, it seems to happen far too soon. 

I am using a laptop with a dual head configuration. The external screen is to the left of the laptop. The graphics card is nVidia and driver is the latest
nVidia driver. (I cannot comment on Nouveaux.) The desktop environment is KDE 4 with 3D effects switched on. 

The external screen is 1280x1024 while the laptop is 1920x1200 so the overall screen width is 3200px wide. 

On the laptop display The menu "switch over" occurs at about 320px, i.e at only about a sixth of the way across the laptop display, and is very off putting as it is entirely unexpected and counter intuitive. (The overall distance from the left hand edge of the external display is about 1740px.)

The behaviour on the external display is ok. The switch over doesn't occur until the menu is very close to the external display's right hand edge and looks pretty good.
Comment 1 daniel 2012-03-29 03:43:50 UTC
I can confirm this behaviour. When I use a dual head configuration with 1280x600 on the internal screen and 1920x1080 on the external one, the menus are places as follows:

Internal screen, maximized:
longer menus are placed right to the main menu item, right at the upper screen border.

Internal screen, not maximized:
the above effect concerns more menus, i.e. also some shorter ones.

External screen, maximized:
All menus are displayed under the main item, but the menus to the right are right aligned.

External screen, not maximized:
All menus are displayed under the main item, but all except the File menu are right aligned.

There is sufficiently much space even on my internal screen to display all menus in the standard way (under the main item, left aligned).
Especially the shifting to the upper screen border is very annoying since the meny hides other main menu items to the right of the current main menu item, so you cannot hover over to the next menu. Instead, you first have to close the current menu before getting access to the menu to the right of it.

If I switch off dual screen mode, all menus behave as they should.


My environment is Ubuntu 11.04 Gnome with 3D effects on.
Comment 2 daniel 2012-03-29 03:45:08 UTC
Created attachment 59213 [details]
Wrong placement of long menu
Comment 3 drodrigue 2012-03-30 10:22:31 UTC
I have the same issue with my setup. I'm running RHEL 6.2 64bit with LibreOffice 3.5.1. I can confirm that the issue did not existed in LibreOffice 3.4.4. I have nvidia driver running in "TwinView" configuration:
-primary display (on left) 1920x1200
-secondary monitor (on right) 1680x1050 (position absolute +1920+0)
Total desktop display size is 3600x1200.

My understanding of the issue is when the window is in the 2nd display area, there's a clipping check with the primary display size instead of the 2nd display. When that occurs, the menu is then displayed at the right position of the mouse (as opposed to the usual left of the mouse). 

There's also a strange behaviour if the window is half-way both screens, not a very useful test case since the window is split between 2 screens, but when the menu does not fit the 1st screen, it will suddenly appear on the 2nd screen. What I find strange is in this is the menu is still left aligned, where I would have expect it to be right aligned and rendered on the 1st screen (clipped to that screen).
Comment 4 Thomas Hackert 2012-09-29 21:25:21 UTC
Hello Owen, *,
as two people have confirmed this issue, I will set it to "New" (I am not able to test it myself, as I have not a second screen on my netbook, sorry ... :( ). If someone thinks, I am wrong here, feel free to switch it back to "Unconfirmed" ... ;)
HTH
Thomas.
Comment 5 QA Administrators 2015-01-05 17:52:25 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of LibreOffice (4.3.5 or later): https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior

If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)

Thank you for your help!

-- The LibreOffice QA Team


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.