40612 - <slider> element causing Mozilla to crash

Status: VERIFIED FIXED

(Core :: XUL, defect, P5)

Description

[Eric Murphy]

I have included an example piece of code that crashes the 5-25 and earlier 
builds. I am just starting to learn XUL, but I cannot understand how such 
simple code would cause a crash.

Comment 1

[Eric Murphy]

<?xml version="1.0"?>

<window
  xmlns:html="http://www.w3.org/TR/REC-html40"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" 
align="vertical">

  <tree>

    <treechildren>

      <treeitem>
        <treerow>
          <treecell value="Eric">Eric</treecell> <!-- The value attribute 
causes it -->
        </treerow>
        <treerow>
          <treecell>Eric</treecell> <!-- This seems to work OK, but nothing is 
displayed? -->
        </treerow>
      </treeitem>

    </treechildren>

  </tree>

</window>

Comment 2

[John Morrison]

Thanks, but that example XUL does not crash on mac/linux/win32 for today's 
release builds. Any other details you can add? (Worksforme).

[On a side note, you should say <treecell><foo>bar</foo></treecell> where
foo is some other xul element. Also add a flex="1" to the tree if it's not
contained within other xul. (The former is correct xul; the latter is a wee
bug)].

Comment 3

[Eric Murphy]

Here is another example that causes a crash. I am really having a hard time 
writing an XUL and looking at examples because of contant crashing. :-( This 
crashed with yesterday's build:

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
<window
  id="example-window"  title="Example 4.2.1"
  xmlns:html="http://www.w3.org/TR/REC-html40"
  xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

  <scrollbar id="scid" curpos="50" maxpos="200"
    increment="5" pageincrement="20">
  <scrollbarbutton type="decrement"/>
  <button value="First"/>
  <slider flex="1"/>
  <button value="Last"/>
  <scrollbarbutton type="increment"/>
</scrollbar>


</window>

Comment 4

[John Morrison]

Okay, that one crashes :-] (By the way, though, it may be more effective to 
work through learning XUL with one of the milestone builds (e.g., M15) as they
have fewer rough spots -- on the other hand, thanks for finding this). 

I get a crash on win32 and linux with the same stack trace. It also 
crashes if I remove the buttons from the example. On windows, from
talkback the stack is : 

nsSliderFrame::AddListener 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsSliderFrame.cpp, line 784] 
nsSliderFrame::SetInitialChildList 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsSliderFrame.cpp, line 658] 
nsCSSFrameConstructor::ConstructXULFrame 
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, 
line 6092] 
nsCSSFrameConstructor::ConstructFrameInternal 
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, 
line 7428] 
nsCSSFrameConstructor::ConstructFrame 
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, 
line 7357] 
nsCSSFrameConstructor::ProcessChildren 
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, 
line 10907] 
nsCSSFrameConstructor::ConstructXULFrame 
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, 
line 6084] 
nsCSSFrameConstructor::ConstructFrameInternal 
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, 
line 7428] 
nsCSSFrameConstructor::ConstructFrame 
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, 
line 7357] 
nsCSSFrameConstructor::ProcessChildren 
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, 
line 10907] 
nsCSSFrameConstructor::ConstructDocElementFrame 
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, 
line 3382] 
nsCSSFrameConstructor::ContentInserted 
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, 
line 8370] 
StyleSetImpl::ContentInserted 
[d:\builds\seamonkey\mozilla\layout\base\src\nsStyleSet.cpp, line 1031] 
PresShell::InitialReflow 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 1595] 
nsXULDocument::StartLayout 
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp, line 3862] 
nsXULDocument::ResumeWalk 
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp, line 5179] 
nsXULDocument::EndLoad 
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp, line 1471] 
XULContentSinkImpl::DidBuildModel 
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULContentSink.cpp, line 556] 
CWellFormedDTD::DidBuildModel 
[d:\builds\seamonkey\mozilla\htmlparser\src\nsWellFormedDTD.cpp, line 315] 
nsParser::DidBuildModel 
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 1005] 
nsParser::ResumeParse [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, 
line 1515] 
nsParser::EnableParser 
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 1108] 
CSSLoaderImpl::Cleanup 
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 746] 
CSSLoaderImpl::SheetComplete 
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 816] 
CSSLoaderImpl::Cleanup 
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 727] 
CSSLoaderImpl::SheetComplete 
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 816] 
CSSLoaderImpl::ParseSheet 
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 851] 
CSSLoaderImpl::DidLoadStyle 
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 887] 
SheetLoadData::OnStreamComplete 
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 684] 
nsStreamLoader::OnStopRequest 
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp, line 122] 
nsFileChannel::OnStopRequest 
[d:\builds\seamonkey\mozilla\netwerk\protocol\file\src\nsFileChannel.cpp, line 
627] 
nsOnStopRequestEvent::HandleEvent 
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 
307] 
nsStreamListenerEvent::HandlePLEvent 
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 
106] 
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 576] 
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, 
line 539] 
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, 
line 1032] 
KERNEL32.DLL + 0x3663 (0xbff73663) 
KERNEL32.DLL + 0x228e0 (0xbff928e0) 
0x00658b4c 

Comment 5

[John Morrison]

Attachment: basic scrollbar xul; 'text/xul' -- WILL CRASH AS OF MAY 26

Comment 6

[Eric Murphy]

I think this bug has something to do with content being bigger than the default 
size of a box (not the <box> tag, but a box in general. I noticed with trees, 
if I make them long (like over 200px tall), it seems to crash.

Sorry I don't have an example handy, but that seems to be a general fact worth 
looking into.

Comment 7

[Eric Murphy]

Also, the problems are in M15 too.

Comment 8

[Peter Trudelle]

assigning to evaughan as p3 for M21. If this is likely to be encountered in a
mozilla app, please nominate for nsbeta2.

Comment 9

[Eric Murphy]

Actually, I am one of the guys working on a Jabber client for Mozilla, so this 
bug is hurting me bad. I can't understand how such simple XUL can cause 
everything to crash.

Basically, I have code that works in M15, but not in the recent builds. I am 
trying to use such things as PNG alpha channels, and also my partner, Jeremie 
Miller has two outstanding bugs, 40664 and 40665

So, I guess I could consider those dependencies.

Thanks!

Comment 10

[leger]

Adding crash to keyword field.

Comment 11

[Eric Murphy]

I have upgraded the severity of this because it is delaying my Jabber for 
Mozilla development. Also see 43262

Comment 12

[Eric Murphy]

These test cases still crash as of June 20th build.

Comment 13

[Peter Trudelle]

We can only work on bugs that either have an externally-contributed fix, or 
have been nominated and approved (dogfood+ or nsbeta2+).

Comment 14

[Eric Vaughan]

Moving to m18

Comment 15

[Peter Trudelle]

Since you haven't nominated this, I'm assuming you found a workaround.  ->Future.

Comment 16

[Peter Trudelle]

The attachment doesn't load for me, but I don't see a crash. Does anyone still
crash?  Should we remove the keyword?  It is showing up in Jan's queries,
despite being target future.

Comment 17

[John Morrison]

The attachment does not load due to bug 41876 [remote XUL that references a 
local chrome:// URL (e.g. a stylesheet) will not work until that is fixed].

However, the attachment loaded from disk still crashes. I had a look at this
some more, and it turns out the <slider/> is broken. E.g., using <slider/>
anywhere in any XUL file will cause a crash (stick <slider/> in navigator.xul
or just use something as simple as this). 

<?xml version="1.0"?>
<window xmlns:html="http://www.w3.org/1999/xhtml"
        xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
  <slider/>
</window>

Obviously, though there are not any clients of <slider/> in the NS6 code base.
However, I do think that this should be addressed for beta3: Since there is 
both internal and external documentation that advertises that this works (when
in fact it crashes), either:

  (1) fix the bit rot if no extensive changes are needed (perhaps it's just 
      a null pointer check required), or

  (2) make <slider/> equivalent to <box/> or <nosuchelement/> when the 
      XUL  content model is created (loss of functionality, but no more crash).

Comment 18

[Peter Trudelle]

could we 3) change the docs to say it crashes?

Comment 19

[John Morrison]

We can get some documents changed, but not all, particularly those developed
by Neil Deakin and zvon.org  (forget the URL's offhand). 

Comment 20

[Peter Trudelle]

nsbeta3+, P5 for M18. Would be good to fix for other moz developers, if 
trivial, but no reason to hold N6 for this.

Comment 21

[leger]

PDT downloading to [nsbeta3-]

Comment 22

[Rich Burridge]

From a cursory investigation, the crash here is in the AddListener() method in:
.../layout/xul/base/src/nsSliderFrame.cpp
 
void 
nsSliderFrame::AddListener() 
{ 
  if (!mMediator) { 
    mMediator = new nsSliderMediator(this); 
    NS_ADDREF(mMediator); 
  } 
 
  nsIFrame* thumbFrame = mFrames.FirstChild(); 
  nsCOMPtr<nsIContent> content; 
  thumbFrame->GetContent(getter_AddRefs(content)); 
 
  nsCOMPtr<nsIDOMEventReceiver> reciever(do_QueryInterface(content)); 
 
  reciever->AddEventListenerByIID(mMediator, NS_GET_IID(nsIDOMMouseListener)); 
} 
 
Using the sample XUL attachment:  
 
  nsIFrame* thumbFrame = mFrames.FirstChild(); 
 
is returning a NULL pointer. I'll investigate further tomorrow...

Comment 23

[Peter Trudelle]

not in Netscape6, ->future

Comment 24

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Nominating for mozilla0.9.  This offers a way for malicious web-page authors to
crash the user's browser (which is, I guess, a form of a denial of service attack).

Comment 25

[John Morrison]

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

Comment 26

[John Morrison]

Change summary from "Minimal XUL Scrollbar causes a SEGV or GPF" [ick!]

Comment 27

[John Morrison]

sigh.

Comment 28

[[e-mail]]

http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/xulBindings.xml#36
Changing this line from <xul:button align="horizontal"/> to
<xul:thumb inherits="align,src" flex="1"/> fixed it for me.

Comment 29

[Eric Vaughan]

fixed

Comment 30

[John Morrison]

crash no more -- win32/linux 2001011021 ...