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




CSS Parsing and Computation
17 years ago
4 years ago


(Reporter: rvj, Assigned: dbaron)



Firefox Tracking Flags

(Not tracked)



(8 attachments)



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

17 years ago
Created attachment 71838 [details]
xul test application

Comment 2

17 years ago
Created attachment 71839 [details]
test case document

Comment 3

17 years ago
Created attachment 71840 [details]
initial css stylesheet

Comment 4

17 years ago
Created attachment 71841 [details]
replacement css sheet

Comment 5

17 years ago
The bug ALSO occurs with stylesheet references that are inserted using 

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 

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

e.g   node0=document.firstChild

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


Summary: table related display properties vanish after stylesheet change → table related display properties vanish after stylesheet change

Comment 6

17 years ago
Created attachment 71856 [details]
insert stylesheet application

Comment 7

17 years ago
Created attachment 71857 [details]
insert  stylesheet  xml

Comment 8

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

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

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

16 years ago
A simpler and better-organized (see comment 10) testcase would be nice here.
Keywords: qawanted

Comment 12

16 years ago

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
Bug 139213.  Basically, just copy the link to the attachment from the attachment

Comment 14

16 years ago
Created attachment 85342 [details]
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


16 years ago
Summary: table related display properties vanish after stylesheet change → [RR/RCF]table related display properties vanish after stylesheet change

Comment 15

16 years ago
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
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"
width="640" > 


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

	pinull = window.frames[0].document.firstChild;
	 pione = pinull.nextSibling;	
	pione.nodeValue = 'type="text/css"




<button label="click here to switch stylesheet"  style="height:30px"   

<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 -->


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. 
Ever confirmed: true
QA->madhur since she has done the most work on this
QA Contact: ian → madhur

Comment 17

13 years ago
Created attachment 184894 [details]
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

13 years ago
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.
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME

Comment 19

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


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


do we use a different DOM root reference for XUL files or is this security?
Resolution: WORKSFORME → ---
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.
Last Resolved: 13 years ago13 years ago
Resolution: --- → WORKSFORME
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.