38589 - Mozilla crashes when certain widgets are made semi-transparent (opacity) [@ nsView::GetDimensions ]

Status: RESOLVED WORKSFORME

(Core Graveyard :: GFX, defect)

Description

[Jeremy Wrinkle]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows 98)
BuildID:    2000050708

 When you specify widgets in the menu.css file with

opacity               : 50%;

and hover over them, Mozilla crashes with this error message:

MOZILLA caused a stack fault in module GKVIEW.DLL at 015f:6034abb7.
Registers:
EAX=00000000 CS=015f EIP=6034abb7 EFLGS=00010212
EBX=00000000 SS=0167 ESP=00591fdc EBP=00592014
ECX=0a83bdf0 DS=0167 ESI=0b384900 FS=7727
EDX=00592030 ES=0167 EDI=00000000 GS=0000
Bytes at CS:EIP:
53 56 8b 75 08 57 33 ff 33 db 39 7d 20 89 4d fc 
Stack dump:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 00000000 00000000 00592084 6034acdb 

However, if you make just the menus semi-transparent (you can see an example of 
this in the URL provided) and hover over them, Mozilla does not crash but the 
hover does not work properly. You have to position the mouse over the menuitem 
just right to click on it. Now, before you say this is stupid and mark 
it "wontfix", I think that you should consider how much people would love this 
feature in Mozilla. No other browser, or any windows program I can think of, 
has semi-tran

Comment 1

[Jeremy Wrinkle]

ew, it cut me off. let me finish: No other browser, or any windows program I 
can think of, has semi-transparent widgets. This is something the XPtoolkit 
crew should work on.

Comment 2

[R.K.Aa.]

Very similar problem is reported in bug 38261

Comment 3

[John Morrison]

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

Comment 4

[John Morrison]

Agreed that this would be a real neat feature, but may not get done
unless someone wants to dig into the code and make this work (i.e., 
helpwanted).

However, crashing is never good :-\ so I suppose that until this 
really works, then this style property should be ignored for XUL
widgets.

The stack trace for this crash is below (loop?)

http://cyclone/reports/SingleIncidentInfo.cfm?dynamicBBID=10136811

nsViewManager2::ProcessPendingUpdates 
  [d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1058] 
nsViewManager2::ProcessPendingUpdates 
  [d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1076] 
nsViewManager2::ProcessPendingUpdates 
  [d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1076] 
nsViewManager2::ProcessPendingUpdates 
  [d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1076] 
nsViewManager2::ProcessPendingUpdates 
  [d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1076] 
nsViewManager2::ProcessPendingUpdates 
  [d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1076] 
nsViewManager2::ProcessPendingUpdates 
  [d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1076] 
nsViewManager2::ProcessPendingUpdates 
  [d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1076] 
nsViewManager2::ProcessPendingUpdates 
  [d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1076] 
nsViewManager2::ProcessPendingUpdates 
  [d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1076] 
nsViewManager2::ProcessPendingUpdates 
  [d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1076] 
nsViewManager2::ProcessPendingUpdates 
  [d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1076] 
nsViewManager2::ProcessPendingUpdates 
  [d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1076] 

Comment 5

[Jeremy Wrinkle]

 Hello, I had an idea for extending the opacity property for widgets. When you 
make a widget semi-transparent, the whole thing becomes semi-transparent. Some 
people might find this annoying. I think we should add onto the opacity 
property the ability to specify background transparency, text transparency, and 
maybe border transparency. Here is an example:

opacity: background=50%, text=100%, border=75%; 

What do you think?

Comment 6

[Peter Trudelle]

I'll take this bug to be about the crash, if you want any other of the 
problems you describe to get attention, please file separate bugs.  Last I 
heard, Beard was working on opacity - reassigning to him, changing severity to 
critical.

Comment 7

[Patrick C. Beard]

This is really a views bug, handing off to the rendering team. Although, it could 
be a lurking GFX bug. I'll take a look and see if I can reproduce it on my 
machine.

Comment 8

[leger]

Adding crash keyword

Comment 9

[Kevin McCluskey (gone)]

This bug has been marked "future" because the original netscape engineer working
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way
-- please attach your concern to the bug for reconsideration.

Comment 10

[Jesse Ruderman]

See also bug 50562, Non-opaque menus don't highlight on mouseover.

Comment 11

[Samuel Sieb]

This crashes on Linux too.

Comment 12

[Kevin McCluskey (gone)]

Build moving all existing future-P3 bugs to future-P4.

Comment 13

[Kai Lahmann (is there, where MNG is)]

hm... none of the links works, and why is a crash set to "enhancement"?

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

this is a crash->critical

Comment 15

[Piotr Malesa]

Attachment: this XUL crashs mozilla

this was tested on firefox 0.9.2 and mozilla 20040331.
if you remove  <scrollbox> or <stack>, this won't crash.
If you remove -moz-opacity this won't crash
strange, if you remove left and top properties, it won't crash

Comment 16

[Adam Hauner]

Stacktrace for testcase:
nsView::GetDimensions
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/view/src/nsView.h]
nsView::GetClippedRect
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp,
line 841]
nsViewManager::UpdateView
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 1738]
nsViewManager::MoveViewTo
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2567]
nsContainerFrame::PositionFrameView
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 512]
nsBox::SetBounds
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBox.cpp,
line 584]
nsStackLayout::Layout
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsStackLayout.cpp,
line 319]
nsContainerBox::DoLayout
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsContainerBox.cpp,
line 612]
nsBox::Layout
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBox.cpp,
line 994]
nsSprocketLayout::Layout
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsSprocketLayout.cpp,
line 520]
nsContainerBox::DoLayout
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsContainerBox.cpp,
line 612]
nsBox::Layout
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBox.cpp,
line 994]
nsScrollBoxFrame::DoLayout
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsScrollBoxFrame.cpp,
line 337]
nsBox::Layout
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBox.cpp,
line 994]
nsSprocketLayout::Layout
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsSprocketLayout.cpp,
line 520]
nsContainerBox::DoLayout
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsContainerBox.cpp,
line 612]
nsBox::Layout
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBox.cpp,
line 994]
nsStackLayout::Layout
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsStackLayout.cpp,
line 322]
nsContainerBox::DoLayout
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsContainerBox.cpp,
line 612]
nsBox::Layout
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBox.cpp,
line 994]
nsBoxFrame::Reflow
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 868]
nsRootBoxFrame::Reflow
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsRootBoxFrame.cpp,
line 240]
nsContainerFrame::ReflowChild
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 982]
ViewportFrame::Reflow
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsViewportFrame.cpp,
line 249]
PresShell::InitialReflow
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 2827]
nsXULDocument::StartLayout
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/content/xul/document/src/nsXULDocument.cpp,
line 2197]
nsXULDocument::ResumeWalk
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/content/xul/document/src/nsXULDocument.cpp,
line 3050]
nsXULDocument::EndLoad
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/content/xul/document/src/nsXULDocument.cpp,
line 746]
XULContentSinkImpl::DidBuildModel
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/content/xul/document/src/nsXULContentSink.cpp,
line 460]
nsExpatDriver::DidBuildModel
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/htmlparser/src/nsExpatDriver.cpp,
line 1060]
nsParser::DidBuildModel
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/htmlparser/src/nsParser.cpp,
line 1248]
nsParser::ResumeParse
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/htmlparser/src/nsParser.cpp,
line 1820]
nsParser::OnStopRequest
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/htmlparser/src/nsParser.cpp,
line 2480]

Comment 17

[:gerard-majax]

When adding an opacity on some elements, such as an input in a form, and then if
you load the page, it failed to load, (still display "transfering ...))? If you
cut off the opacity from the CSS, then you have to close and reopen Mozilla or
FireFox, otherwise it won't load the page !

i haven't opened a new bug, because it seems linked to this one.

Comment 18

[Adam Hauner]

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

Comment 19

[Andrew Schultz]

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

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This works for me now. Can people recheck this on a fresh nightly build?

Comment 21

[Martijn Wargers (dead)]

Yes, testcase works for me too, using 2005-04-16 trunk build. Marking wfm.

Comment 22

[Jesse Ruderman]

Crashtest added as part of http://hg.mozilla.org/mozilla-central/rev/5a6def05ccbc