Closed
Bug 283154
Opened 20 years ago
Closed 17 years ago
Branch Hang/crash using tabpanels *:hover{display:-moz-popup;} and then reloading page
Categories
(Core :: Web Painting, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: martijn.martijn, Assigned: roc)
References
Details
(Keywords: crash, testcase, Whiteboard: [xul frame construction])
Attachments
(2 files)
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
Reporter | ||
Comment 1•20 years ago
|
||
Reporter | ||
Comment 2•20 years ago
|
||
It's crashing directly in Mozilla1.4 and Mozilla1.7, so this is not a regression.
Comment 3•20 years ago
|
||
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
![]() |
||
Comment 4•20 years ago
|
||
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?
![]() |
||
Updated•20 years ago
|
Whiteboard: [xul frame construction]
Comment 5•20 years ago
|
||
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
Reporter | ||
Comment 6•19 years ago
|
||
This is WFM with 2006-1-1 trunk build.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Comment 7•19 years ago
|
||
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060102 Firefox/1.6a1
WFM
Updated•19 years ago
|
Status: RESOLVED → VERIFIED
Comment 8•18 years ago
|
||
Still crashes Firefox 2.0.0.4-rc1 on Linux. TB31941005
Status: VERIFIED → REOPENED
OS: Windows 2000 → Linux
Resolution: WORKSFORME → ---
Comment 9•18 years ago
|
||
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
Reporter | ||
Comment 10•18 years ago
|
||
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
Reporter | ||
Comment 11•17 years ago
|
||
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 ago → 17 years ago
Resolution: --- → WORKSFORME
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•