Closed Bug 282059 Opened 20 years ago Closed 19 years ago

No dropshadow in Windows XP in current trunk builds for context menus and tooltips

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 281709

People

(Reporter: martijn.martijn, Unassigned)

References

Details

(Keywords: regression) 

This is a spin-off of bug 281709.

When you have dropshadows enabled in Windows XP, you should see these
dropshadows for context menu items and tooltips. But this is currently not
working in Mozilla builds.

This worked in: 
20041011 07:23am Firefox build
But not anymore in:
20041012 07:18am firefox build

Boris mentioned about this bug in  bug 281709, comment 15:
"The context menu and tooltips issue sounds like fallout from bug 238493. To
test, remove the early return at
<http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/view/src/nsView.cpp&rev=3.210#370>.

Sounds like the general problem is that someone is (incorrectly) expecting
something to happen synchronously at all times."
FWIW this problem also affects the autocomplete popups for form fields.  Unlike
select lists (see bug 146719) the autocomplete popups do have shadows in 1.0 and
1.0.1.

Seems to me that this should be fixed for 1.1 considering that it could be
noticed as a regression by even a novice user (who is paying attention).  Even
though it is trivial in terms of functionality, it diminishes the very polished
feel of the app a bit.
I have also been suffering from this with the nightly Trunks for a few months now.
WinXP SP2
AMD64 300+
Geforce 6800GT
Flags: blocking-aviary1.1?
transferring nomination to 1.8b4. If we don't get it there, we don't get it for 1.1
Flags: blocking-aviary1.1? → blocking1.8b4?
Flags: blocking1.8b4? → blocking1.8b4-
I have also been suffering from this as well for a good number of months.
XP SP2
AMD64 3000+
Geforce 6800


Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050805
Firefox/1.0+
Flags: blocking1.9a1?
*** Bug 300319 has been marked as a duplicate of this bug. ***
I just noticed that submenu's of the context menu (e.g This Frame ->)have
dropshadows.
(In reply to comment #6)
> I just noticed that submenu's of the context menu (e.g This Frame ->)have
> dropshadows.

[URL=http://imageshack.us][IMG]http://img381.imageshack.us/img381/6463/shadowmess1oi.jpg[/IMG]
(In reply to comment #7)
> (In reply to comment #6)
> > I just noticed that submenu's of the context menu (e.g This Frame ->)have
> > dropshadows.
> 
> Sorry...<a href="http://ietpower.com/orange/shadow_mess.jpg">picture</a>
*** Bug 307541 has been marked as a duplicate of this bug. ***
mconnor: what is the reason for minusing the blocking1.8b5 nomination?  this
regression makes popup menus look bad.  is it just too hard to fix for 1.5?
I'm pleading for reconsideration for 1.8b5 -- regressions like this make us look
wrong to a number of users, based on the dominant commodity platforms.  This has
been noticed, by random users even including managers ;-).

/be
Flags: blocking1.8b5- → blocking1.8b5?
I have no firm recollection of reasoning here, although I think at that time we
were throwing things overboard at a rapid clip trying to make the branch happen
for July 25th, and a beta by mid-August.  Anything cosmetic that didn't have a
straightforward fix or an obvious owner we could rely on for a fast turnaround
was getting tossed based on that short short timeline.  Something in win32
widget code certainly meets that criteria even now.

Now that we've stretched the schedule significantly, we can and should put some
time into this/bug 281709, though I'm not sure who an appropriate owner would be
here, unless Ere is active/responsive, or we can retask dougt for this (based
solely on owners.html).
Flags: blocking1.9a1?
Flags: blocking1.8b5?
Flags: blocking1.8b5+
Ben had me assign bug 307541 to Kevin Gerich, but that bug was marked as a
duplicate of this one, which has no owner.  Kevin: can you help fix this?
Assignee: nobody → kevin
Darin, sorry I didn't say this earlier... I don't think I'm the right person to
fix this bug. This isn't a theme issue AFAICT
(In reply to comment #14)
> Darin, sorry I didn't say this earlier... I don't think I'm the right person to
> fix this bug. This isn't a theme issue AFAICT

Oh, sorry.  I assigned it to you because this was introduced with the check-in
for bug 303806, which was merely a theme change.  But, that's okay... I'll
re-assign this bug to mconnor since he owned that bug ;-)
Assignee: kevin → mconnor
(In reply to comment #15)
> Oh, sorry.  I assigned it to you because this was introduced with the check-in
> for bug 303806, which was merely a theme change.  But, that's okay... I'll
> re-assign this bug to mconnor since he owned that bug ;-)

Per comment 0, this isn't a regression from the theme changes. Backing out the
changes from bug 303806 does not fix this.
OK.  I guess I was confused then because I first noticed this regression when
the theme changes landed.  Must have been a coincidence then :-P
Silver, any ideas on how this could be fixed?  Bug 281709 has some discussion,
but I don't know the Windows widget code much, so I'm not sure how to fix this
right.
Assignee: mconnor → nobody
Whiteboard: [at risk]
I don't know exactly what is wrong (currently investigating), but it is quite
likely the window is being created with the wrong size, then resized later
(whether this is the cause, I don't know). See what I can turn up. :)
Right, so top-level menus get the best deal: only created once per menu,
positioned once, then resized just before being shown.

Context menus get a really rough ride, being created /every time/, hidden,
shown, moved and resized - in that order.

Submenus get a deal very similar to top-level menus, except for an extra
(unnessessary) call to hide them before they've even been shown.

So I'm fairly sure the problem is the following really bad ordering of calls to
nsWindow:

[9307ec] CreateWindowEx: style = c2000000, ex_style = 88, parent = 0, DROP SHADOW
[9307ec] Show: state = 0
[9307ec] Show: state = 1
[9307ec] Move to (212, 788)
[9307ec] Resize to (166, 246), repaint = 1
See bug 281709 for some detailed analysis of what's going on.
Is this a dup of bug 281709?
Actually isn't bug 281709 fixed?  That was originally about shadows not showing
the first time a menu was opened in the bookmarks toolbar.  I haven't seen that
bug in months.  It seems that bug 282359 fixed it.  That bug spun off this bug
which is about shadows not being present in context menus.  So the question is
why wasn't that bug resovled?  I'm guessing because some people aren't cc'd to
this bug.  So discussion proceeded in that bug.

But it's moot now as there's a patch from bug 281709 checked into the trunk
which seems to work so both bugs can shortly be resolved.  
Yeah, bug 281709 was originally about just the menu shadows, but the comments 
evolved into working on the shadows more generally. Also, that bug was way 
more technical than this one, which is why I did the work over there. Once bug 
281709 is checked to be properly fixed, this bug is fixed too AIUI.

*** This bug has been marked as a duplicate of 281709 ***
Status: NEW → RESOLVED
Closed: 19 years ago
No longer depends on: 281709
Flags: blocking1.8b5+
Resolution: --- → DUPLICATE
Well, a fix for bug 281709 landed on the trunk and this bug is still on the trunk.
That would be because they are DIFFERENT BUGS, and so need to be fixed separately.
That was my point.
So you think that two different bugs, that must be fixed separately, should
suddenly both end up fixed by the same thing? Huh?
Um, this is marked as a duplicate of bug 281709. My point was that it shouldn't be.
Then what was the comment on bug 243078 all about?

This bug is marked a dup of bug 281709 because that bug actually covers (in the
comments and attempted code) this one.
If a bug is a duplicate, then by definition, when the duplicate is fixed, so too
is the duplicate. If one is fixed and the other is not, then they are not
duplicates.

The reason I asked why native menu rendering landed and this bug persisted was
because I thought the native menu rendering overlaid the drop-shadow onto the
window. I was not aware that the drop-shadow is drawn by the window onto which
it falls.
(In reply to comment #26)
> Well, a fix for bug 281709 landed on the trunk and this bug is still on the trunk.

bug 281709 never landed on the trunk, only the 1.8 branch
Whiteboard: [at risk]
(In reply to comment #33)
> (In reply to comment #26)
> > Well, a fix for bug 281709 landed on the trunk and this bug is still on the trunk.
> 
> bug 281709 never landed on the trunk, only the 1.8 branch


------- Comment #111 From Robert O'Callahan (Novell) 2005-10-20 19:40 PST [reply] ------- checked in on trunk and branch. (https://bugzilla.mozilla.org/show_bug.cgi?id=281709#c111)
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.