<slider> element causing Mozilla to crash

VERIFIED FIXED in mozilla0.8

Status

()

Core
XUL
P5
critical
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: Eric Murphy, Assigned: Eric Vaughan)

Tracking

({crash, helpwanted})

Trunk
mozilla0.8
crash, helpwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3-][minus])

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
<?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

18 years ago
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)].
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 3

18 years ago
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

18 years ago
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 

Severity: normal → critical
Status: RESOLVED → UNCONFIRMED
Keywords: crash
Resolution: WORKSFORME → ---
Summary: Minimal XUL Tree causes a crash → Minimal XUL Scrollbar causes a crash

Updated

18 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

18 years ago
Created attachment 9216 [details]
basic scrollbar xul;  'text/xul' -- WILL CRASH AS OF MAY 26
(Reporter)

Comment 6

18 years ago
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.
(Reporter)

Comment 7

18 years ago
Also, the problems are in M15 too.

Comment 8

18 years ago
assigning to evaughan as p3 for M21. If this is likely to be encountered in a
mozilla app, please nominate for nsbeta2.
Assignee: trudelle → evaughan
Severity: critical → normal
Component: XP Toolkit/Widgets: XUL → XP Toolkit/Widgets
Keywords: crash
OS: Windows 2000 → Linux
QA Contact: jrgm → chrisd
Target Milestone: --- → M21
(Reporter)

Comment 9

18 years ago
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

18 years ago
Adding crash to keyword field.
Keywords: crash
(Reporter)

Comment 11

18 years ago
I have upgraded the severity of this because it is delaying my Jabber for 
Mozilla development. Also see 43262
Severity: normal → blocker
Depends on: 43262
Target Milestone: M21 → M17
(Reporter)

Updated

18 years ago
Severity: blocker → normal
No longer depends on: 43262
Target Milestone: M17 → M21
(Reporter)

Comment 12

18 years ago
These test cases still crash as of June 20th build.
(Reporter)

Updated

18 years ago
Severity: normal → blocker
Target Milestone: M21 → M17
(Reporter)

Updated

18 years ago
Blocks: 43262

Comment 13

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

Comment 14

18 years ago
Moving to m18
Status: NEW → ASSIGNED
Target Milestone: M17 → M18

Updated

18 years ago
QA Contact: chrisd → jrgm

Comment 15

18 years ago
Since you haven't nominated this, I'm assuming you found a workaround.  ->Future.
Target Milestone: M18 → Future

Comment 16

18 years ago
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

18 years ago
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).
Severity: blocker → critical
Keywords: helpwanted, nsbeta3
OS: Linux → All
Hardware: PC → All
Summary: Minimal XUL Scrollbar causes a crash → Minimal XUL Scrollbar causes a SEGV or GPF

Comment 18

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

Comment 19

18 years ago
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

18 years ago
nsbeta3+, P5 for M18. Would be good to fix for other moz developers, if 
trivial, but no reason to hold N6 for this.
Priority: P3 → P5
Whiteboard: [nsbeta3+]
Target Milestone: Future → M18

Comment 21

18 years ago
PDT downloading to [nsbeta3-]
Whiteboard: [nsbeta3+] → [nsbeta3-][minus]

Comment 22

18 years ago
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

18 years ago
not in Netscape6, ->future
Target Milestone: M18 → Future
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).
Keywords: mozilla0.9
(Assignee)

Updated

17 years ago
Target Milestone: Future → mozilla0.8

Comment 25

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

Comment 26

17 years ago
Change summary from "Minimal XUL Scrollbar causes a SEGV or GPF" [ick!]
Summary: Minimal XUL Scrollbar causes a SEGV or GPF

Comment 27

17 years ago
sigh.
Summary: <slider> element causing Mozilla to crash

Comment 28

17 years ago
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.
(Assignee)

Comment 29

17 years ago
fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → FIXED

Comment 30

17 years ago
crash no more -- win32/linux 2001011021 ...
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.