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)

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: