Download it now!
Bug 77913 - Menus are getting invisible when hovering
Summary: Menus are getting invisible when hovering
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected) Master
Hardware: All All
: highest blocker
Assignee: Not Assigned
Keywords: regression
: 77933 77956 77983 (view as bug list)
Depends on:
Blocks: mab4.3
  Show dependency treegraph
Reported: 2014-04-25 06:45 UTC by Florian Reisinger
Modified: 2014-06-14 13:48 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

Showing the error in a 4.3 alpha1+ master (28.82 KB, image/png)
2014-04-25 06:45 UTC, Florian Reisinger

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Reisinger 2014-04-25 06:45:56 UTC
Created attachment 97940 [details]
Showing the error in a 4.3 alpha1+ master

Please have a look at the attached screenshot for more infos. It is difficult to describe. All other menu entries are invisible, but the current on with
Build ID: 808d273db098e2269e53813595a6bfc7b160e28e
TinderBox: Win-x86@39, Branch:master, Time: 2014-04-25_02:09:26
With another daily from 2014-04-20 and from another thinderbox the behaviour is as expected.

Not well working core-functions -> critical-high + regression keyword
Comment 1 Luke 2014-04-25 20:40:16 UTC
This is not just a 64 bit windows bug. After I did a "git reset --hard origin/master" the menu's were all blank, except when the mouse is hovering over an item.

$ lsb_release -rcd ; uname -rm
Description:	Linux Mint 16 Petra
Release:	16
Codename:	petra
3.11.0-12-generic i686

As a temp workaround, you can do a:
$ SAL_USE_VCLPLUGIN=gen ./soffice
Comment 2 manj_k 2014-04-25 23:03:25 UTC
*** Bug 77933 has been marked as a duplicate of this bug. ***
Comment 3 Julien Nabet 2014-04-26 05:30:24 UTC
On pc Debian x86-64 with master sources updated today, I can reproduce this.
When just hovering menus without try to select an entry it's ok, but when you hover inside any menu, only the current entry of the menu displays.
It's not a crash but it's a big regression of a core basic feature used a lot by a lot of people, IMHO it's a blocker.
Comment 4 Julien Nabet 2014-04-26 05:32:10 UTC
Chris/Caolán: one for you? (vcl part I suppose)
Comment 5 Julien Nabet 2014-04-26 06:10:25 UTC
When I gave a try to fdo#77934, I saw that the bug was also present in context menus (which appears with right click)
Comment 6 Jorendc 2014-04-26 13:02:33 UTC
*** Bug 77956 has been marked as a duplicate of this bug. ***
Comment 7 Julien Nabet 2014-04-26 16:23:19 UTC
I think this commit 0ef2999f7b498686ad38749b93f0591dd52bcc50 solved the problem.
At least, it's ok right now after having updated local master sources.

Florian/Joren/Luke: Could you give a try with master sources updated after this commit?
Comment 8 Joel Madero 2014-04-26 22:14:06 UTC
Just checked and it is resolved! Thanks :)
Comment 9 manj_k 2014-04-26 23:37:16 UTC
*** Bug 77983 has been marked as a duplicate of this bug. ***
Comment 10 Chris Sherlock 2014-04-26 23:54:08 UTC
Caolan's commit message explains what happened here:

given the explanation of MenuFloatingWindow::InitClipRegion() it should not be virtual then prior to 95711f5b9e7b6a982d1762d37d5a38e0f40b86f9 the menu ImplInitClipRegion had nothing to do with the outdev ImplInitClipRegion and so all the original ImplInitClipRegion calls here should now be routed to InitMenuClipRegion which was removed by "In fact InitMenuClipRegion() is unused" so restore that.

In other words, Windows derives from OutputDevice and this had a virtual function IntiClipRegion. However, MenuFloatingWindow derives indirectly from Window, but it used the function InitClipRegion for an entirely different purpose. When it was made virtual, it caused this issue.
Comment 11 Jorendc 2014-04-27 10:34:39 UTC
Verified using windows 8.1 using Version:
Build ID: 145f2e970f46a3a3e5456b122d71f17c3abe878f
TinderBox: Win-x86@42, Branch:master, Time: 2014-04-26_23:32:36

Kind regards,