Closed Bug 186224 Opened 22 years ago Closed 19 years ago

XSLT cache is never invalidated

Categories

(Core :: XSLT, defect)

Product:
Core
Component:
XSLT
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: horndog, Assigned: peterv)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212

If you view an XML file with a XSLT processing instruction, Mozilla renders
perfectly.  If you edit the XSLT after you view the transformation, the
transformation does not reflect the changes.  XML updates correctly update the
transformation however.


Reproducible: Always

Steps to Reproduce:
1. View XML page with XSLT processing instruction
2. Edit XSLT
3. View XML page again noting that changes are not visible

Actual Results:  
Results of updated XSLT transformation are not seen.  The cached value remains.

Expected Results:  
Changing the XSLT should change the output.

Tested on Mac, Linux, and Windows.  Also affects Phoenix (or whatever it will be
called these days).  All versions with XSLT-functionality affected.  This should
be of minimal impact to end users as 99.999% of all client-side-XSLT-oriented
sites use static XSLT.  However, for development, it is a real time sink.

Workaround: Enter the XSLT URL in the browser and view directly.  Hit
shift-reload.  Return to original page.
should this be sent off to network?
Miles: I take it shift-reload doesn't work when viewing the xml-page that links
to the xslt?
No, shift-reload doesn't work.  It was one of the first things that I tried. 
Also, the files were served static so it's clear that LastModified headers
aren't being checked.

The only way I could find to clear things up was to load the XSLT URL explicitly
 and hit reload on just the stylesheet.  Only then do the updates show up. 
Going back to the XML w/ processing instruction afterward showed the updated
translation.

...make another XSLT edit, wash, rinse, repeat.

I love the client-side XSLT support and it hasn't crashed on me or given
incorrect output.  The cache bug's just annoying for development.

gordon, we'd need cache advice here.
I think that the loadFlags of the channel control wether the load validates
the cache or not. Here is what we do, is there anything that is supposed to be
done differently?

We set the loadgroup on the channel of the stylesheet to the loadgroup of the
document, 
http://lxr.mozilla.org/seamonkey/source/content/xml/document/src/nsXMLContentSink.cpp#758
and call ::AsyncOpen on it,
http://lxr.mozilla.org/seamonkey/source/content/xml/document/src/nsXMLContentSink.cpp#784
which AFAICT, adds the channel/request to the loadgroup.
This merges the loadflags, at least for nsHttpChannel.
So shouldn't the loadflags be set allright?
Darin, can you take a look at how they setting loadflags in comment #4.
i agree with comment #4, but perhaps a HTTP log would help.

NSPR_LOG_MODULES=nsHttp:5

then you'll be able to see exactly what the HTTP code is doing.  who knows..
maybe the load group has the wrong load flags somehow?!?
*** Bug 155715 has been marked as a duplicate of this bug. ***
*** Bug 126794 has been marked as a duplicate of this bug. ***
confirming based on the number of dups
Status: UNCONFIRMED → NEW
Ever confirmed: true
I can't reproduce this. I verified with the http logs from Mozilla and in the
server logs, changing the stylesheet causes Mozilla to refetch it.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
(In reply to comment #10)
I'm sorry, lost track of this bug over the years so I didn't report a fix. It
has since been fixed, but it wasn't by me, and I don't know in which build.

Seeing as how I opened the bug, I figure it would be worth mentioning that it
works for me now too.
marking verified per reporters comment
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.