128207 - [RR/RCF]table related display properties vanish after stylesheet change

Status: RESOLVED WORKSFORME

(Core :: CSS Parsing and Computation, defect)

Description

[rvj]

If an xml document has elements that use the display property to map css table 
elements then these elements disappear (tablerows and tablerow) if the 
stylesheet is changed via the processing instruction interface

Elements that that do  not use/refer to the display property correctly have the 
style properties applied (header and footer) in the test case attachment

Comment 1

[rvj]

Attachment: xul test application

Comment 2

[rvj]

Attachment: test case document

Comment 3

[rvj]

Attachment: initial css stylesheet

Comment 4

[rvj]

Attachment: replacement css sheet

Comment 5

[rvj]

The bug ALSO occurs with stylesheet references that are inserted using 
createProcessingInstruction

In the test case that follows the stylesheet is inserted but styling is only 
applied to non-display elements 

PS I also noticed what seems to be an inconsistancy as regards  child node 
selection.

In the previous earlier test case, the stylesheet is referenced as the second 
child node

e.g   node0=document.firstChild
      styling=node0.nextSibling

When inserting a stylesheet reference, it does not seem to matter. Can anyone 
clarify?

 

Comment 6

[rvj]

Attachment: insert stylesheet application

Comment 7

[rvj]

Attachment: insert stylesheet xml

Comment 8

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

Could you describe how to use all the files attached to demonstrate the bug?  In
the future, it would be nice if you attached them to the bug so that they could
be used just by clicking on them (that is, attach the CSS first, and then change
the link in the XML to point to the attached CSS file).  But right now I see 6
files linking to each other by name without hints as to what each should be named.

Comment 9

[rvj]

OK will do

1. The first four files are used to test stylesheet switching by setting 
nodeValue. In order these are

a) refresh.xul - a replacement test case  with iframe and code for stylesheet 
switching (from oldsheet.css to newsheet.css)
b) refresh.xml - the xml document containing a stylesheet reference to the 
initial (oldsheet.css) file
c) oldsheet.css - the initial css stylesheet
d) newsheet.css - the replacement stylesheet


2. The last two files are used to test stylesheet insertion using 
createprocessinginstruction
a) insert.xul - an insertion test case with iframe  and code for stylesheet 
insertion (will insert newsheet.css)
b) insert.xml - the xml document WITHOUT a stylesheet reference


It appears the bug affects both stylesheet switching and stylesheet insertion

but the stylesheet switching test case shows the problem the best .

Comment 10

[Boris Zbarsky [:bzbarsky]]

If you could attach the files in reverse order (attach CSS, change XUL to point
to the version of the CSS in bugzilla, attach JS, change XUL to point to JS in
bugzilla, attach XUL) this would be much easier to debug and would maybe even
get some attention...

Comment 11

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

A simpler and better-organized (see comment 10) testcase would be nice here.

Comment 12

[rvj]

Could you suggest an example bug report where files have been submitted in this 
way .

Im not entirely sure I know what bugzilla directory to point to

Comment 13

[Boris Zbarsky [:bzbarsky]]

Bug 139213.  Basically, just copy the link to the attachment from the attachment
list....

Comment 14

[Madhur Bhatia]

Attachment: first testfile attached - an XML file

re-attaching the testcases provided by the reporter with correct/usable
stylesheet link

using attachment 71840 [details] as the initial stylesheet link

Comment 15

[Madhur Bhatia]

I was trying to update the xul file provided in attachment 71838 [details], by changing
the 1. src to the newstylesheet from a relative uri to an absolute uri
(http:///bugzilla.mozilla.org/showattachment.cgi?attach_id=71841) 
2. src to the iframe from a relative uri to an absolute uri
(http://bugzilla.mozilla.org/showattachment.cgi?attach_id=85342 OR any other
http://... uri)

for some reason, when i did step 2, the script calling function 'pi' fails to
execute (that is - when user clicks on the button, the old stylesheet
[attachment 71840 [details]] should be replaced by the new stylesheet [attachment 71841 [details]]) 

According to http://www.w3.org/TR/REC-html40/present/frames.html#edef-IFRAME , i
should be ablie to include an absolute uri in the iframe src. hmmmmm .....
I am failing to do so.  

** this is a seperate issue from the original bug mentioned by the reporter. I
suppose another bug should be opened for this. **

When I provide a relative uri in the iframe src, i do see the bug described by
the reporter. But due to the above mentioned problem , i am not able to attach
the updated xul file.

here is the source code for the xul file i was updating to show the bug :-
=========================
<?xml version="1.0"?> <!-- -*- Mode: HTML -*- -->

<window id="refresh" 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"
  height="480"
width="640" > 


<script>

function pi() {
	
	// first stylesheet reference is second child node

	pinull = window.frames[0].document.firstChild;
	 pione = pinull.nextSibling;	
	pione.nodeValue = 'type="text/css"
href="http://bugzilla.mozilla.org/showattachment.cgi?attach_id=71841"';

	

}

</script>

<button label="click here to switch stylesheet"  style="height:30px"   
onclick="pi()"/>

<iframe  id='iframe' style="width:640px;height:400px" src="http://bugzilla.mozilla.org/showattachment.cgi?attach_id=85342"/>	

<!-- if I change this src to a relative uri, i am able to reproduce the bug -->

</window>
=======================================================

Since, I am able to reproduce the bug  (as described by reporter), i am
confirming the bug. I will try to find an alternative way to write a
reproducible testcase for this bug for the time being. 
Thanks!

Comment 16

[Hixie (not reading bugmail)]

QA->madhur since she has done the most work on this

Comment 17

[Andrew Schultz]

Attachment: testcase that hopefully works

this testcase works locally using relative URLs.  Linking to b.m.o and loading
locally causes security exceptions.

Anyway, the testcase works fine with linux trunk 2005052705 and 1.7, although
it shows up with 1.0 and 1.4.

Comment 18

[Andrew Schultz]

ok, the testcase works fine as an attachment.

testcase works fine with trunk builds and exhibits bug described in comment 0
with older builds.

resolving WORKSFORME
if I'm misinterpreting comment 0, please reopen.

Comment 19

[rvj]

if the contents of the iframe is a xul file (rather than one of type xml) then stylesheet switching does not take effect.

in fact even attempting to display the nodeValue  returns null

    alert(window.frames[0].document.firstChild.nodeValue)

NB at least using the href attribute does return the location of the stylesheet
to be replaced

    alert(window.frames[0].document.styleSheets[0].href)

do we use a different DOM root reference for XUL files or is this security?

Comment 20

[Boris Zbarsky [:bzbarsky]]

Comment 19 is unrelated to this bug (XUL and tables have nothing to do with each other).  Please file a separate bug on that issue, attach a testcase that shows the problem, and cc me.