312120 - [FIX]Should consider not parsing XUL display types when MOZ_XUL not defined

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Boris Zbarsky [:bzbarsky]]

At the moment, we parse all the XUL display types no matter what, as far as I
can tell.  But for some of them we only create XUL boxes #ifdef MOZ_XUL.  Which
means we'll fall into ConstructFrameByDisplayType, assert, and crash if someone
uses those display types in a build without MOZ_XUL.

That said, do we still support building without MOZ_XUL?

Comment 1

[Benjamin Smedberg]

No. Let's just ditch the ifdef.

Comment 2

[Doug Turner (:dougt)]

Yes, we care about MOZ_XUL.  Do NOT remove MOZ_XUL. 

XUL continues to be an option.  It saves about 1mb RSS last I checked on linux arm.

Comment 3

[Boris Zbarsky [:bzbarsky]]

OK.  I wasn't sure what the state of minimo and XUL was, since you were working
on a XUL front-end, Doug.

So if we support this then we need to fix this issue... :(

Comment 4

[Boris Zbarsky [:bzbarsky]]

Alternately, we could parse the -moz-* display types involved as "inline" or
something if xul is disabled.  Not sure which is better.

Comment 5

[Doug Turner (:dougt)]

no worries.  we shouldn't go out of our way to break MOZ_XUL; alot of time has
gone into making sure that it does work.  How hard is it to fix the problem?

doug

Comment 6

[Boris Zbarsky [:bzbarsky]]

Depends on how we want to fix it.   If we want to just treat those display types
as unknown in builds without MOZ_XUL, it's a matter of adding an ifdef in the
table at http://lxr.mozilla.org/seamonkey/source/layout/style/nsCSSProps.cpp#509
to match whatever ifdefs nsCSSFrameConstructor::ConstructXULFrame has.

Comment 7

[Doug Turner (:dougt)]

I would take that approach.  It seams the safest, easiest, and most direct. 
Give me a patch and I can test.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Like so

Comment 9

[Boris Zbarsky [:bzbarsky]]

Fixed.