Closed Bug 40118 Opened 20 years ago Closed 20 years ago

Crash in il_PermitLoad or GetClipView on this URL


(Core :: Layout, defect, P1)






(Reporter: bozhan, Assigned: attinasi)




(Keywords: crash, testcase, Whiteboard: [nsbeta2+] (py8ieh:track new bug))


(3 files)

From Bugzilla Helper:
User-Agent: Mozilla/4.73 [en] (Win98; I)
BuildID:    20000521

MOzilla crash when i try to open this page. i think there is some problems whit 

Reproducible: Always
Steps to Reproduce:
1.start mozilla
2.go to
3.choose bulgarian

Actual Results:  mozilla crash

Expected Results:  have to display page
Reproduced on PC/Linux, build 2000052109. Confirming, adding crash kw, 
severity critical, adding new info to summary. Stack trace:

#0  0x40035312 in il_PermitLoad ()
#1  0x40035612 in IL_GetImage ()
#2  0x4002d654 in ImageRequestImpl::Init ()
#3  0x40027f1e in ImageGroupImpl::GetImage ()
#4  0x40ec64de in nsFrameImageLoader::Init ()
   from components/
#5  0x40edaa92 in nsPresContext::StartLoadImage ()
   from components/
#6  0x40e163c6 in nsCSSRendering::PaintBackground ()
   from components/
#7  0x40cc7313 in nsHTMLContainerFrame::Paint ()
   from components/
#8  0x40e81780 in nsBoxFrame::Paint ()
   from components/
#9  0x40cf2499 in nsGfxScrollFrame::Paint ()
   from components/
#10 0x40cb95cf in nsContainerFrame::PaintChild ()
   from components/
#11 0x40cb94a4 in nsContainerFrame::PaintChildren ()
   from components/
#12 0x40cb9440 in nsContainerFrame::Paint ()
   from components/
#13 0x40ce2253 in PresShell::Paint ()
   from components/
#14 0x41099938 in nsView::Paint ()
   from components/
#15 0x410a87a6 in nsViewManager2::RenderDisplayListElement ()
   from components/
#16 0x410a85ee in nsViewManager2::RenderViews ()
   from components/
#17 0x410a82fb in nsViewManager2::Refresh ()
   from components/
#18 0x410a97f8 in nsViewManager2::DispatchEvent ()
   from components/
#19 0x4109947f in HandleEvent ()
   from components/
#20 0x406384da in nsWidget::DispatchEvent ()
   from components/
#21 0x406383ea in nsWidget::DispatchWindowEvent ()
   from components/
#22 0x4063f1f3 in nsWindow::SendExposeEvent ()
   from components/
#23 0x4063fe97 in nsWindow::HandleXlibExposeEvent ()
   from components/
#24 0x406324b7 in handle_xlib_bin_event ()
   from components/
#25 0x401a7c0e in gdk_superwin_bin_filter ()
#26 0x4079e92b in gdk_event_apply_filters (xevent=0xbfffeee0, event=0x8215c00, 
    filters=0x8307b88) at gdkevents.c:946
#27 0x4079ea66 in gdk_event_translate (event=0x8215c00, xevent=0xbfffeee0)
    at gdkevents.c:1027
#28 0x4079fa87 in gdk_events_queue () at gdkevents.c:2014
#29 0x4079fc8c in gdk_event_dispatch (source_data=0x0, 
    current_time=0xbfffefc8, user_data=0x0) at gdkevents.c:2092
#30 0x407cf4d3 in g_main_dispatch (current_time=0xbfffefc8) at gmain.c:652
#31 0x407cfb0b in g_main_iterate (block=1, dispatch=1) at gmain.c:870
#32 0x407cfcc1 in g_main_run (loop=0x820fb90) at gmain.c:928
#33 0x406eef0b in gtk_main () at gtkmain.c:475
#34 0x4062a7de in nsAppShell::Run ()
   from components/
#35 0x403b2e2e in nsAppShellService::Run ()
   from components/
#36 0x804d2e7 in main1 ()
#37 0x804d785 in main ()
#38 0x40265213 in __libc_start_main (main=0x804d640 <main>, argc=1, 
    argv=0xbffff1f4, init=0x804a780 <_init>, fini=0x8052380 <_fini>, 
    rtld_fini=0x4000ac30 <_dl_fini>, stack_end=0xbffff1ec)
    at ../sysdeps/generic/libc-start.c:90
Severity: normal → critical
Ever confirmed: true
Keywords: crash
OS: Windows 98 → All
Summary: crash if i choose bulgarian language → Crash in il_PermitLoad on this URL, choose bulgarian language
IMG3250.DLL performed an invalid memory access.

Module Name: IMG3250.DLL

Application Name: Mozilla.exe

If the Taskbar is behaving strangely, try exiting Keyboard Language Indicator 

Description: Keyboard Language Indicator Applet
Version: 4.10.2222
Product: Microsoft(R) Windows(R) Operating System
Manufacturer: Microsoft Corporation

The stack trace has changed between 5/21 and 5/25. 
Now the crash does not happen in any more. 
Instead, it looks like this:
 #0 -  #8  
 #9 - #14
#15 - #19
#20 gdk_superwin_resize () from
#21 0x4074192b in gdk_event_apply_filters (xevent=0xbfffef80, event=0x8244238, 
Attached image motion3.jpg
Attached file testcase.html
The above testcase is quite simple:

  <textarea style="background-image: url('motion3.jpg'); background-attachment:

When loading this testcase from a local file system, the 5/21 build crashes 
with a stack trace that matches the second one above:

#0  0x40e3c20d in GetClipView ()                       from
#1  0x40e3c719 in nsCSSRendering::PaintBackground ()   from
#2  0x40ced313 in nsHTMLContainerFrame::Paint ()       from
#3  0x40ea7780 in nsBoxFrame::Paint ()                 from
#4  0x40d18499 in nsGfxScrollFrame::Paint ()           from
#5  0x40cdf5cf in nsContainerFrame::PaintChild ()      from
#6  0x40cdf4a4 in nsContainerFrame::PaintChildren ()   from
#7  0x40cdf440 in nsContainerFrame::Paint ()           from
#8  0x40d08253 in PresShell::Paint ()                  from
#9  0x41099938 in nsView::Paint ()                     from
#10 0x410a87a6 in nsViewManager2::RenderDisplayListElement () 
#11 0x410a85ee in nsViewManager2::RenderViews ()       from
#12 0x410a82fb in nsViewManager2::Refresh ()           from
#13 0x410a97f8 in nsViewManager2::DispatchEvent ()     from
#14 0x4109947f in HandleEvent ()                       from
#15 0x406384da in nsWidget::DispatchEvent ()           from
#16 0x406383ea in nsWidget::DispatchWindowEvent ()     from
#17 0x4063f1f3 in nsWindow::SendExposeEvent ()         from
#18 0x4063fe97 in nsWindow::HandleXlibExposeEvent ()   from
#19 0x406324b7 in handle_xlib_bin_event ()             from
#20 0x401a7c0e in gdk_superwin_bin_filter ()           from

When loading the attachment directly (note that in the testcase.html attachment
'motion3.jpg' has been replaced with the URL of the first attachment), the 5/21
build crashes in il_PermitLoad with a stack trace where the entries #0 - #8 are
identical to the one above.

This bug is rather old. M14 doesn't seem to crash, but e.g. the 3/29 build does
(this is the oldest one I have installed).
Adding testcase keyword, changing component to Layout, reassigning to default
owner, CC'ing troy (author of GetClipView) and self.
Assignee: asadotzler → clayton
Component: Browser-General → Layout
Keywords: testcase
QA Contact: jelwell → petersen
Summary: Crash in il_PermitLoad on this URL, choose bulgarian language → Crash in il_PermitLoad or GetClipView on this URL
I see the crash too.  Giving bug to Mark [ not 100% sure if it is his ].  Mark 
could you redirect this to the right person.
Assignee: clayton → attinasi
The problem is in nsCSSRendering::PaintBackground - the code is broken for 
GfxScrollbars because of the way it is getting the view for the scrollable 
frame. We need to convert this to use the nsIScrollabelFrame interface. That 
fixes the crash, but there are still problems in painting the fixed-position 
image (offsets are not correctly computed). 

(Note that turning off GfxScollbars makes the crash go away, but does nto 
entirely fix the bug.)
Target Milestone: --- → M16
This will crash on any site with a fixed background on a textarea element, and 
probably other elements as well (fixed-backgrounds on the body are fine, 
Keywords: nsbeta2
Priority: P3 → P1
Hardware: PC → All
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [nsbeta2+]
I have a fix for the crash, however the fixed-attachment part os still not 
working, so the image is scrolling. I'll spend a little more time on that and 
try to fix it, but if I cannot then I suggest we check in the crash-fix and 
enter another bug on fixed-attachment background images not working on textarea 
controls (I'm quite sure that this has never worked, even without 
Whiteboard: [nsbeta2+] → [nsbeta2+] (py8ieh:track new bug)
OK, now the fixed attachment is not scrolling, however there is still a problem 
where the scrollbars on the textarea are getting painted over. I'll check in the 
fix as is and open another bug on the scrollbar painting problem. 

Attaching a patch...
Fixed. (nsDocumentViewer.cpp,nsFrameManager.cpp)
Closed: 20 years ago
Resolution: --- → FIXED
Oops - wrong file listed: (nsCSSRendering.cpp) sorry...
Fixed in the June 19th build (2000061908).
You need to log in before you can comment on or make changes to this bug.