Closed
Bug 128207
Opened 22 years ago
Closed 19 years ago
[RR/RCF]table related display properties vanish after stylesheet change
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: rvj, Assigned: dbaron)
Details
Attachments
(8 files)
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
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?
Summary: table related display properties vanish after stylesheet change → table related display properties vanish after stylesheet change
Assignee | ||
Comment 8•22 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.
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•22 years ago
|
||
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...
Assignee | ||
Comment 11•22 years ago
|
||
A simpler and better-organized (see comment 10) testcase would be nice here.
Keywords: qawanted
Reporter | ||
Comment 12•22 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
Comment 13•22 years ago
|
||
Bug 139213. Basically, just copy the link to the attachment from the attachment list....
Comment 14•22 years ago
|
||
re-attaching the testcases provided by the reporter with correct/usable
stylesheet link
using attachment 71840 [details] as the initial stylesheet link
Assignee | ||
Updated•22 years ago
|
Summary: table related display properties vanish after stylesheet change → [RR/RCF]table related display properties vanish after stylesheet change
Comment 15•22 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 (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!
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 16•21 years ago
|
||
QA->madhur since she has done the most work on this
QA Contact: ian → madhur
Comment 17•19 years ago
|
||
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•19 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.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 19•19 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 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?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 20•19 years ago
|
||
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.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•