11101 - [DOGFOOD] Garbage bits under XP menus

Status: VERIFIED FIXED

(Core :: XUL, defect, P2)

Description

[Dan Rosen]

the "new" menu bar (the one with the grippie) is busted: random bits and pieces
of junk fill the area where the menus ought to be when moused-over. looks like
an xlib or rendering problem... system is rh6, xfree 3.3.3.1

Comment 1

[don]

Pam, is this a bug for you?

Comment 2

[pnunn]

probably not, but I'll check it out and reassign as necessary.
-pn

Comment 3

[leger]

Per Don, setting to XP Toolkit and setting to M9.

Comment 4

[leger]

Updating QA Contact

Comment 5

[Dan Rosen]

looks like somebody has hacked at the xp menus a bit, and they're looking a
little better in the 1999040601 build, but not golden yet... symptoms still
include a blank x window either in the corner of the screen or where the menu
should be, appearing and disappearing erratically, and some (less than before)
garbage under xp menus. a new symptom is improper layout: the menu items all run
into each other with no spacing above, below or between. there's also a typo in
the qa menu, but that's probably not of much concern right now ;)

Comment 6

[Dan Rosen]

looking better still in 1999080408, still some garbage bits but not as much.
menu item spacing is fixed, and arrow icons for cascading menus are showing up.
a new problem is that the underlining of the letter corresponding to keypress
("accelerator?" my terminology is rusty...) shows up too high up in the text.
this may be another symptom of <a href="show_bug.cgi?11168">bug 11168</a>.

Comment 7

[Dan Rosen]

oops. should have figured bugzilla would be smarter than i...

Comment 8

[David Hyatt]

Giving pav a chance to look at it.  cc'ing Ramiro, who can tell if this is a
more general problem also affecting the combo box.

Comment 9

[Dan Rosen]

try this to reproduce a no-junk situation:
click and hold on a menu item (in the menu bar), mouse over to an adjacent menu
item, mouse back to the previous menu item. no junk (at least for me), although
there still seem to be extraneous or oversized x windows popping up...

i am still wondering whether the underline thing here and bug 11168 are two
instances of a more generic underline bug having to do with fonts or some
such...

Comment 10

[Stuart Parmenter]

this i believe is a different problem.  the menus being created are too big,
which is causing from what i can tell the view manager to ignore things below
the extra window size when expose events come across.  I havn't looked at this
in great detail, but this is my guess.

Comment 11

[Stuart Parmenter]

*** Bug 11086 has been marked as a duplicate of this bug. ***

Comment 12

[Stuart Parmenter]

*** Bug 11086 has been marked as a duplicate of this bug. ***

Comment 13

[Stuart Parmenter]

adding PP

Comment 14

[Dan Rosen]

Things are looking *much* better in the 1999081001 build. The menus appear to be
created at the correct size now, and the resulting garbage is significantly
less. The only remaining garbage occurs when the active menu is closed.

Comment 15

[Stuart Parmenter]

I know where the problem is, but I am not sure why it is happening.  I need to
talk to owen taylor, but he isn't going to be reachable for a few more days, so
I am moving this to M10.

Comment 16

[ramiro]

I think the clipping region is wrong.

Comment 17

[Dan Rosen]

i'm not sure exactly what "dogfood" means, but i have maybe a little more
information which might reinforce what ramiro just said. i tried slowing down my
already fairly slow computer by bogging the memory down with lots of running
programs, to the point where apprunner was cached entirely on disk. when i
opened a menu item, a blank box the size of a menu list flashed on the screen in
the wrong place (ie. not where the menu was supposed to be) and then went away.
i can't guarantee this "means" anything, but it might help...

Comment 18

[Stuart Parmenter]

i'm seeing worse things in the last few days.  Does anyone know what is required
to make these Show() AFTER they are Resize()d?  I have a feeling this will make
things better.  Hyatt?

Comment 19

[Stuart Parmenter]

*** Bug 11910 has been marked as a duplicate of this bug. ***

Comment 20

[Stuart Parmenter]

*** Bug 11910 has been marked as a duplicate of this bug. ***

Comment 21

[Stuart Parmenter]

*** Bug 13190 has been marked as a duplicate of this bug. ***

Comment 22

[cpratt]

just as an fyi, 'dogfood' is expanded from the phrase 'eating your own dogfood',
ie using the mozilla browser as your primary web browser. bugs marked 'dogfood'
are marked thusly to indicate a basic problem with the browser that must be
fixed before we will use the browser as our primary browser.

Comment 23

[Stuart Parmenter]

reassigning to saari.  this happens on all platforms (unix and win32 since mac
doesn't use xp menus).  random things draw on the chrome when a mouse moves off
of it.

Comment 24

[saari (gone)]

Hyatt/Pavlov, did the popup CID change fix this?

Comment 25

[James Everingham]

Not necessary for dogfood.

Comment 26

[Stuart Parmenter]

uhh.. this is pretty important.  things look really dumb with this.  it was
needed for dogfood as of the porkjockies meeting

Comment 27

[Stuart Parmenter]

this is my bug.. stealing from saari

Comment 28

[Stuart Parmenter]

really reassign it

Comment 29

[leger]

Putting on the PDT+ radar.

Comment 30

[saari (gone)]

I don't see this happening anymore on my Windows build. Has this gone away with
Pav's painting changes?

Moving to M12 since it looks fixed to me and I can't repro.

Comment 31

[Dan Rosen]

I think this was only ever an Xwindows bug (solaris, linux) which would handily
explain why you're not seeing a problem on Win32 :)

I was curious about the status of this recently so I checked it out a couple
days ago, and the problem was still there although probably 90% fixed. The
problem had seemed to have gone away for a while, but when the new chrome was
added to the builds, the problem seemed to be back (the back button was showing
residual junk on the menu covering it).

There is the possibility that this problem has actually been fixed and what I'm
seeing now is a problem with XPFE (transparencies or something, just a guess)
but it's safest I guess to keep this bug open until we can prove it's been
squashed :) ... in the meantime, I'd suggest checking out whatever chrome code
might be relevant.

Comment 32

[Peter Trudelle]

really, really reassigning to pav

Comment 33

[Stuart Parmenter]

fixed.

Comment 34

[leger]

Setting QA contact.

Comment 35

[Dan Rosen]

I don't know what you were seeing, pavlov, but the bug still isn't quite gone.
On the M11 solaris build, the "stop" button still causes junk under the "edit"
menu. Oddly, it is the only button that causes this problem, and the only menu
in which the problem appears, so this may be a problem with the chrome itself.

Comment 36

[Sebastian Späth]

What I see, is actually not drawing junk, but e.g. in a mailnews window the mail
icons and the white of the toolbar icons "shines" still through the menus (build
11/20)

Not seeing this in Windoze. Most probably X only bug

Comment 37

[leger]

Clearing FIXED resolution due to reopen.

Comment 38

[Jim Roskind]

Removed PDT+ to get a re-evaluation.  Trudelle indicated that this is now down
to a "cosmetic" defect, and doesn't think it will stop folks from using the
product as dogfood (certainly we still need to fix it for FCS, and even beta).

Comment 39

[kinmoz]

*** Bug 19393 has been marked as a duplicate of this bug. ***

Comment 40

[leger]

Putting on PDT- radar.

Comment 41

[Hervé Renault]

i'm adding a screenshot to this one (it may be useful to illustrate)

here's how i did :

in composer, pulled down the "Help" menu
  => everything's ok
and then put the cursor on the "image" button without rolling the menu up
  => the "Image" active button appears through the menu.

(using today's CVS sources, built on Linux SuSE 6.2)

Comment 42

[Hervé Renault]

Attachment: png image to show buttons that appear through XP menus when you mouse over the buttons

Comment 43

[Stuart Parmenter]

this bug has had many meanings.. the latest one that i closed it for was crap
staying on the screen when menus go away.  the one you reopened it for is bug
#16018 which just states a bit more clearly what the bug is..

Comment 44

[Paul MacQuiddy]

v

Comment 45

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cd4651651abd
[components] Ignore deprecations for tracking protection exceptions they will be covered on https://github.com/mozilla-mobile/android-components/issues/11101
https://hg.mozilla.org/integration/autoland/rev/f4d4aeb8bc3d
[components] Closes https://github.com/mozilla-mobile/android-components/issues/11101 Expose API to allow to persist tracking protection exceptions in private mode