Closed Bug 283154 Opened 19 years ago Closed 17 years ago

Branch Hang/crash using tabpanels *:hover{display:-moz-popup;} and then reloading page

Categories

(Core :: Web Painting, defect)

1.8 Branch
x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: martijn.martijn, Assigned: roc)

References

Details

(Keywords: crash, testcase, Whiteboard: [xul frame construction])

Attachments

(2 files)

460 bytes, application/vnd.mozilla.xul+xml
Details
4.58 KB, text/plain
Details
The following testcase hangs/crashes when you hover over the textbox and then
press reload.

The stacktrace is probably not meaningful here. One talkback ID I got is: TB3859027Z
Attached file Testcase
It's crashing directly in Mozilla1.4 and Mozilla1.7, so this is not a regression.
From my optimized with symbols build (Gecko/20050217) after hovering a few times
very fast:

nsViewManager::UpdateWidgetArea(nsViewManager * const 0x02632568, nsView *
0x02d6ffe0, const nsRegion & {...}, nsView * 0x00000000) line 1811 + 6 bytes
nsViewManager::ProcessPendingUpdates(nsViewManager * const 0x02632568, nsView *
0x011c019e) line 1625
nsViewManager::FlushPendingInvalidates(nsViewManager * const 0x02632568) line 4265
nsViewManager::EndUpdateViewBatch(nsViewManager * const 0x02632568, unsigned int
0) line 3416 + 10 bytes
ReflowEvent::HandleEvent(ReflowEvent * const 0x02632568) line 6149
PL_HandleEvent(PLEvent * 0x027a4248) line 699
PL_ProcessPendingEvents(PLEventQueue * 0x0084b654) line 633 + 6 bytes
_md_EventReceiverProc(HWND__ * 0x7cd669c0, unsigned int 0, unsigned int 1244724,
long 2094425737) line 1436
USER32! 7cd951e6()
USER32! 7cd951e6()
GKWIDGET! 013c4729()
MOZILLA! 004073b0()
KERNEL32! 77e50abc(
Assignee: nobody → roc
Component: Layout → Layout: View Rendering
QA Contact: layout → ian
Hmm... I don't even have to reload.  Just hovering a few times does it.

The problem seems to be that when we get the view for the child widget in
nsViewManager::UpdateWidgetArea, it has 0x1 as mViewManager.  So getting the
root view manager crashes.

So why do we have a widget with a destroyed view hanging off of it, exactly?
Whiteboard: [xul frame construction]
Attached file Stacktrace
Todays trunk build (Mac OS) This crash is still in. I get this assertion many 
times:

###!!! ASSERTION: We already have a window for this view? BAD: '!mWindow', file
../../../../src/view/src/nsView.cpp, line 608

and then this stacktrace
Blocks: 321106
This is WFM with 2006-1-1 trunk build.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060102 Firefox/1.6a1

WFM
Status: RESOLVED → VERIFIED
Still crashes Firefox 2.0.0.4-rc1 on Linux.  TB31941005
Status: VERIFIED → REOPENED
OS: Windows 2000 → Linux
Resolution: WORKSFORME → ---
Doesn't seem to crash on Firefox trunk nightly build on Linux though.
The assertion in comment 5 makes me suspect it's related to bug 374102.
Depends on: 374102
Morphing this into a branch bug, since it doesn't seem to crash anymore on trunk.
Summary: Hang/crash using tabpanels *:hover{display:-moz-popup;} and then reloading page → Branch Hang/crash using tabpanels *:hover{display:-moz-popup;} and then reloading page
Version: Trunk → 1.8 Branch
This is also worksforme on the branch now:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.10) Gecko/20071115 Firefox/2.0.0.10
Status: REOPENED → RESOLVED
Closed: 19 years ago17 years ago
Resolution: --- → WORKSFORME
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: