Closed Bug 38761 Opened 24 years ago Closed 23 years ago

Dynamically changing 'href' attribute of <link> doesn't work

Categories

(Core :: DOM: CSS Object Model, defect, P3)

Product:
Core
Component:
DOM: CSS Object Model
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.2

People

(Reporter: rsalesas, Assigned: peterv)

References

(
URL
)

Details

(Keywords: dom2, Whiteboard: [Hixie-P4] (py8ieh: also check for XML PI, HTTP headers, META elements, STYLE elements, @import, etc))

Attachments

(4 files)

Don't call UpdateStylesheet twice.
2.57 KB, patch
Details | Diff | Splinter Review
Reduced testcase (first stylesheet)
129 bytes, text/css
Details
Reduced testcase (second stylesheet)
131 bytes, text/css
Details
Reduced testcase
1.40 KB, text/html
Details 
The following page and stylesheets should change the paragraph from red to 
green, but they don't because Mozilla doesn't allow access to the stylesheet 
object. Of course, this works in IE (and is darn cool too).

Tested on Navigator Preview Release.


red.css 
======
p { color:red }

green.css 
======
p { color:green }


test.html
=====

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html>
<head>
	<title>Untitled</title>
	<link id="styles1" rel="stylesheet" type="text/css" href="red.css">
	
	<script>
		function changeStyleSheet() {
			var styles1 = document.getElementById("styles1");
			styles1.setAttribute("href", "green.css");
		}	
	</script>
</head>

<body>

<p>Paragraph!</p>

<input type="button" onclick="changeStyleSheet()">

</body>
</html>
Assignee: pierre → jst
Status: UNCONFIRMED → NEW
Component: Style System → DOM Level 2
Ever confirmed: true
QA Contact: chrisd → vidur
Confirmed and reassigned to DOM Level 2 for investigation.

How bad will it be if this is not fixed for FCS? Is there a workaround? If you 
use the DOM to blow away and replace the LINK element, does that work? (Yes, 
that's not ideal, but the goal at this point is only to make sure that vitally 
needed operations can be successfully accomplishe by at least one 
standards-compliant technique--even if there are other, easier means one would 
prefer.)
Removing a link element doesn't remove the stylesheet associated with the link
element, nor does adding a link element cause a stylesheet to be loaded. We
should at least support removing and adding stylesheets by removing or adding
link elements, and once that is done (there's an other bug on that) fixing this
should be simple IMO.
Status: NEW → ASSIGNED
Changing summary to reflect the real problem
Summary: Stylesheet href property does not respect being reset → Setting linkelmnt,href does not unload/load stylesheet
This bug has been marked "future" because the original netscape engineer
working on this is over-burdened. If you feel this is an error, that you or
another known resource will be working on this bug,or if it blocks your work
in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: --- → Future
I do not understand. Does this mean that Mozilla will *not* support dynamically 
changing stylesheets? This is a serious flaw. Changing stylesheets dynamically 
is essential in a web app.


Hopefully we'd be able to fix this sometime soon now, this is a dup of 7515 tho.

*** This bug has been marked as a duplicate of 7515 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
vrfy dup
Status: RESOLVED → VERIFIED
Component: DOM Level 2 → DOM Style
Unduplicating. This bug is slightly different and the fix to bug 7515 did not
fix this bug.

See: http://www.dieselnet.com/ -- click on the "Links are not underlined" text
in the header.
Blocks: html4.01
URL: http://www.dieselnet.com/
Status: VERIFIED → REOPENED
Keywords: dom2, qawanted
QA Contact: vidur → ian
Resolution: DUPLICATE → ---
Summary: Setting linkelmnt,href does not unload/load stylesheet → Dynamically changing 'href' attribute of <link> doesn't work
Whiteboard: [Hixie-P4] (py8ieh: also check for XML PI, HTTP headers, META elements, STYLE elements, @import, etc)
Reassigning to peterv, who fixed 7515.
Assignee: jst → peterv
Status: REOPENED → NEW
We were calling UpdateStylesheet twice, which seemed to cause the problem at
www.dieselnet.com. This patch solves the problem for me.
Status: NEW → ASSIGNED
OS: Windows 2000 → All
Hardware: PC → All
Target Milestone: Future → mozilla0.9.2
Looking for r and sr.
peterv: Just curious - why is calling UpdateStyleSheet() twice bad?
Yeah, I'd like to know why the patch fixes the problem as well. Without knowing
why, we could regress something else.
Sorry for the late response, I'd already gone off to check for the "real"
problem :). The issue is that UpdateStylesheet doesn't know about
still-loading-stylesheets. So if the stylesheet hasn't finished loading yet, and
you call it again it'll happily load another copy. So we end up with two copies
of the same stylesheet. Changing the link again would delete only one copy, and
load the other stylesheet. Because a copy of the first one is still around, the
links' "underline" doesn't change.
I'm nearly done making a patch for that, but this first patch needs to go in
too. There's no need to call UpdateStylesheet twice for the same attribute
change, once is enough even if we'd bail out the second time (patch coming for
that).
Attached file Reduced testcase — 

    
    

    
  
Okay, r=heikki for the current patch. Are you going to attach another patch here
or make a new bug for it (if new bug please Cc me)?

    
    

    
  
Opened bug 85631 for the real issue, which is much harder to hit after this fix
goes in. It would involve changing the href again through JS before the load
from a previous change has finished. (In this testcase it involves clicking
incredibly fast on the underlined/not underlind link.)

    
    

    
  
sr=jst

    
    

    
  
a=blizzard on behalf of drivers for the trunk

    
    

    
  
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
verified using testcase
Status: RESOLVED → VERIFIED
Keywords: qawanted

    
    

    
  
Thank you - this helped fix the links in use on our used mixer trucks section of our site http://www.mixertrucks.com

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: