138290 - {ib}[RR/RCF]Stylesheet change not creating new frames [AltSS]

Status: RESOLVED WORKSFORME

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

Description

[Katsuhiko Momoi]

** Observed with 2002-04-13 1.00 branch build and latest trunk builds **

I have a multiple stylesheet demo for -moz liststyles for an XML file 
that used to work with 0.9.4 builds such as Netscape 6.2.1 but 
currently this does not work at all.

The demo file called "listc.xml" has the main stylesheet and 5 other 
alternate stylesheets associated with it. When you open the XML file,
you will see the effect of the default stylesheet, i.e. simplified 
chinese formal list style.

There are 5 others liststyles. When you choose alternate stylesheets via
View | Use Style menu, all the alternate style sheets lead to a blank page.

I will attach a demo file set next.

This is a critical bug -- it makes our showcase demo unusable for one
thing. I would like to see this fixed as soon as possible.

Comment 1

[Katsuhiko Momoi]

Attachment: .zip file containing all the demo files.

Unarchive the .zip file into a directory and open the listc.xml
file with the current build. Use the View | Use Style menu to try to
switch from the default style to others. They will all produce a blank
page.
This works with Netscape 6.2.2 (0.9.4).

Comment 2

[Katsuhiko Momoi]

This bug disables the functioning of a menu item. Nominating
for nsbeta1.

Comment 3

[Hixie (not reading bugmail)]

In future please attach the test cases directly to Bugzilla (not in a zip file)
as that makes it a lot easier te test the bug and therefore improves the chances
of anyone looking at it...

Comment 4

[Hixie (not reading bugmail)]

Attachment: Testcase: Change to the alternate stylesheet to test

Comment 5

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

In Ian's testcase, it looks like, in the frame reconstruct following the
reresolve, the inline frame for test disappears but the block frame isn't
created in its place.

Comment 6

[Hixie (not reading bugmail)]

It appears the problem is somewhat more serious. We are not reconstructing any
frames, it seems. For example, see:

   http://www.scottcollins.net/journal/

Some affected frames disappear, but none reappear.

Comment 7

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

Does anyone have any idea when this regressed?

Comment 8

[Scott Collins]

I'm glad to see people noticed this before I did.  I'm pretty sure this worked
in 0.9.9.  I'm not _positive_ (but close), so I'll try to pull and build by date
to help narrow the time down.

Comment 9

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

I'd like to look at this for 1.0 (assuming it doesn't happen too soon), but I'm
afraid it might be a lot of debugging if I don't have an idea what changes might
have caused it...

Comment 10

[Boris Zbarsky [:bzbarsky]]

The testcase in comment #4 works in 2001-12-13-08 and fails in 2002-01-07-06
(both linux nightlies).

This is the time period in which stylesheet switching started using
ReResolveStyleContext instead of just reframing everything, no?

Comment 11

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

Right, that was 12-17, so that was the cause of this regression.

Comment 12

[Madhur Bhatia]

cc'ing myself

Comment 13

[Hixie (not reading bugmail)]

scc just pointed out to me that his site works again on the trunk. The testcase,
however, does not. So they were separate regressions after all.

Comment 14

[Boris Zbarsky [:bzbarsky]]

The following variations work correctly:

1)  <doc> block before and after sheet switch
2)  <doc> block before sheet switch and inline after sheet switch
3)  <dov> inline before sheet swithc and block after sheet switch

So the real problem here is that the _only_ place where we test for possible new
{ib} situations is in ConstructInline.  In the attached testcase the re-resolve
causes a block frame to be created and appended to the child list of the inline,
but we don't detect it as an {ib} situation and do not do the magic inline
splitting.  The <doc> element's frame is never touched, so we never call
ConstructInline in this case.

Comment 15

[Madhur Bhatia]

adding keyword 'testcase' since Ian has attached one.

Comment 16

[Samir Gehani]

adt: nsbeta1-

Comment 17

[Anne (:annevk)]

-> WFM

Comment 18

[Boris Zbarsky [:bzbarsky]]

Anne, the testcase probably "wfm" because the root element is now forced to be a
block.  Try wrapping another inline around the block, and the problem should be
nicely visible...