complete loss of style when executing a certain javascript

RESOLVED FIXED in mozilla0.9.4



DOM: CSS Object Model
17 years ago
3 years ago


(Reporter: Wolfgang Schwarz, Assigned: peterv)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [Hixie-P3], URL)


(1 attachment)



17 years ago
On, if you click the link "Element
Labels", all style rules for the entire document will be lost. This is what that
link does:

<a class="b" href="javascript:
function z7T0(par){
  for(var i=0; i<par.childNodes.length;	i++){
    var z=par.childNodes[i];
    z.title='tagName: '+z.tagName+'\nid: '+( || '[none]')
    +'\nparentNode: '+(z.parentNode.tagName || '[none]')
    +'\nchildren: '+z.childNodes.length;

If I find some time I'll try to isolate that problem further.

Tested with NB 2001-07-18-03 and M0.91 on win98.
OK.  Here is the problem.  document.documentElement is <html>, not <body>.

So you end up resetting the "title" attribute of the <style> element.

Looks like we're deapplying the stylesheet when that happens, because which
stylesheet is applied depends on the title, of course. Thing is, title seems to
be only magical for <link> styles, not <style> styles.

setting status to NEW and over to style system to decide whether this is
actually a bug.

Wolfgang, if you getElementById to get the <style> element and change its title
in IE, does the style get lost?  Does document.documentElement return <html> or
<body> in IE?
Assignee: jst → pierre
Component: DOM Style → Style System
Ever confirmed: true

Comment 2

17 years ago
document.documentElement is <html> in IE as well, but changing the <style>'s 
title does never affect the layout, no matter how I access it (tested with 
getElementById, getElementsByTagName and document...childNodes[...]).

Comment 3

17 years ago
This is a regression added by peterv on May 18 2001 while working on bug 7515.

When the <style>'s title is changed we call nsHTMLStyleElement::SetAttribute() 
and then nsStyleLinkElement::UpdateStyleSheet() which has for function to remove 
a stylesheet and load it all over again.  Problem: to reload the stylesheet, 
UpdateStyleSheet() needs an URL, which it doesn't have in this particular case 
because the styles comes from a <style> element, not from a linked stylesheet. It 
means that the <style> element's stylesheet is removed and nothing is re-
inserted: all the style disappears.

1) What kind of attributes can change on the <style> element?  Is there any that 
require an update of the stylesheet?  If so, nsHTMLStyleElement may need to 
implement its own version of UpdateStyleSheet() instead of reusing the one from 

2) In the case of a linked stylesheet, should all the attributes cause an update 
of the stylesheet?  Can't we do an update for just a small list of attributes?

Reassigned to DOM Style.
Assignee: pierre → jst
Component: Style System → DOM Style
Keywords: regression
> 1) What kind of attributes can change on the <style> element?

type, media, title

When the type is changed, we probably want to reload the stylesheet (in case it
is no longer CSS), right?  When media is changed do we need to reload the
stylesheet?  And for title changing we don't need to.

2) In the case of a linked stylesheet, should all the attributes cause an update 
of the stylesheet?

Well..  we need to update for title, href, type, and rel.  The other attributes
of a <LINK> element should not cause updates, being inapplicable to stylesheets.

Comment 5

17 years ago
reassigned to peterv, like bug 83981 which is also related to bug 7515
Assignee: jst → peterv
Depends on: 7515

Comment 6

17 years ago
my apologies: bug 83981 is a different problem
Mozilla should consider the title attribute of <style> elements to be equivalent
to the title attribute of <link> elements. (IE doesn't support this.)
Keywords: qawanted
Whiteboard: [Hixie-P3]

Comment 8

17 years ago
Attaching a patch. Internally, inline stylesheets have the document URL as their
URL, so we need to compare with that if the href is empty. I think the updating
of the stylesheets when any of the other attributes change should be filed as a
separate RFE.

Comment 9

17 years ago
Created attachment 43512 [details] [diff] [review]
Compare with the document url

Comment 10

17 years ago


17 years ago
Priority: -- → P2
Target Milestone: --- → mozilla0.9.4
Documents don't always have base url's, you should check for a null base url and
ask for the document url if there's no base url. With that, sr=jst

Comment 12

17 years ago
Jst, but then the loader would use a null url, no? See
 I don't see how I could handle that at all.
Ignore my comments about documents not always having a base URI.

Comment 14

17 years ago
Checked in.
Last Resolved: 17 years ago
Resolution: --- → FIXED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.