Closed Bug 231255 Opened 21 years ago Closed 19 years ago

sometimes Javascript displays as HTML when pipelining is enabled

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: bradley.plies, Assigned: darin.moz)

References

(
URL
)

Details

(Whiteboard: [pipelining]) 

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: Mozilla 1.6 Gecko/20040113, Mozilla 1.5 Gecko/20030916 , FireBird 0.7 Gecko/20031007, Netscape 7.1 Gecko/20030624

Page validates as HTML 4.01 Transitional compliant via 
http://validator.w3.org/detailed.html

Javascript is rendered and some regular HTML disappears about 70% of the time 
in the following browsers: Mozilla 1.6 Gecko/20040113, Mozilla 1.5 
Gecko/20030916, FireBird 0.7 Gecko/20031007, Netscape 7.1 Gecko/20030624.  IE
works just fine.

If you keep hitting Reload, you may get a properly rendered page.  Page source 
is identical regardless of correct rendering.  Saving a local copy of the bad 
rendering then opening the local copy always renders correctly.  Strange how by 
reloading the page, the browser can randomly decide to render the same source 
differently.  Some sort of timing issue?

This bug is similar to Bug 97886 and Bug 66013 which have been assigned (to 
someone who is gone??) and stale for about 2.5 years.  Unlike in the case of 
Bug 66013 this page is valid HTML and does not use document.write() to include 
a javascript source file.

Reproducible: Sometimes

Steps to Reproduce:
1. Visit URL
2. Hit reload a few times to "roll the dice" for alternating good/bad renderings
3.

Actual Results:  
Sometimes get javascript displayed in place of regular HTML content.

Expected Results:  
Keep the javascript from being displayed and not hide regular HTML content
<!-->
before JavaScript, have to look up the specs if this is to be considered
beginning and end of a comment simultaneously... in this case the page would be
wrong.

End of JS block is 
//End --&gt;
Ugh! This &gt; is what should be a >

Opera and IE
In case the URL provided in the textbox above disappears, here it is again:
http://www.bulliondirect.com/catalog/selectProducts.do?category=9

In the case of saving a local copy of a bad render, the included javascript 
file in the HTML source is probably not saved on your computer which is 
probably why it will render correctly.  That javascript file does indeed use 
document.write() as the other referenced bugs, but not to render a '<script 
src="..">' and simply a 'document.write("<\!--")'
Strange... after some reloading I get the page completely and the part says:
--------------------------------------------------
<script type="text/javascript" language="Javascript1.1"> 

<!-- Begin 

     var bCancel = false; 

    function validateAddToCartForm(form) {                                     
                             
        if (bCancel) 
      return true; 
        else 
       return validateRequired(form) && validateInteger(form); 
   } 

    function required () { 
     this.aa = new Array("category", "category is required.", new Function
("varName", " return this[varName];"));
    } 

    function IntegerValidations () { 
     this.aa = new Array("category", "category must be an integer.", new
Function ("varName", " return this[varName];"));
    } 



function validateFloatRange(form) {
                var isValid = true;
                var focusField = null;
                var i = 0;
                var fields = new Array();
                oRange = new floatRange();
                for (x in oRange) {
                    var field = form[oRange[x][0]];
                    
                    if ((field.type == 'text' ||
                         field.type == 'textarea') &&
                        (field.value.length > 0)) {
                        
                        var fMin = parseFloat(oRange[x][2]("min"));
-------------------------------------------------------
instead of simply:
-------------------------------------------------------
<script type="text/javascript" language="Javascript1.1"> 

<!-->  0)) {
                        
                        var fMin = parseFloat(oRange[x][2]("min"));
-------------------------------------------------------

Is there some part simply missing??
Caching problem?
I have a temporary test server available at: 
http://logician.dnsalias.org/catalog/selectProducts.do?category=9 where I have 
made some minor tweaks in the javascript areas.  The problem is not gone, but 
the frequency has reduced considerably.  First-access seems to still render 
incorrectly, but if you reload it once and thereafter it renders correctly.

Changes include removing "<!--//-->" occurances, and 
fixed '...type="text/javascript">></script>' 
to '...type="text/javascript"></script>'

Mr. Kunz, I am not sure what you mean about missing parts, but this page is 
complete.  Thanks for checking so far though.
The problem is pipelining turned on. I can't reproduce with pipelining off, with
pipelining on i can
Component: Browser-General → Networking: HTTP
.
Assignee: general → darin
QA Contact: general → httpqa
confirming so
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Javascript displays as HTML, some regular HTML unrendered → sometimes Javascript displays as HTML when pipelining is enabled
Whiteboard: [pipelining]
Pipelining hmmm.   Is that feature shared with the other affected Gecko-using 
browsers?  Also, just for my reference, before toggling pipelining did you 
clear your cache?
Brad: with missing parts I meant what the page source shows, not what the page
on the server is like.
Pipelining seems to affect the probability of this happening after several tests
with clearing cache each time, but I usually have pipelining disabled and I saw
the problem when I first loaded the page, so it cannot be the only problem.

All current browsers support at least optionally HTTP 1.1 pipelining, not just
Gecko-based ones...

For missing parts, the answer is no.  A locally saved correctly renedered page 
(regardless of browser) acceptably passes file comparison (windows: fc, linux: 
diff) with a badly rendered one.  By acceptably, I mean no structural 
differences and only different sessionID's in the links.  Even the whitespace 
is the same.
Clearing cache gives this error in the JS console:
Error: uncaught exception: [Exception... "Component returned failure code:
0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsICacheService.evictEntries]"  nsresult:
"0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame ::
chrome://communicator/content/pref/pref-cache.js :: prefClearCache :: line 89" 
data: no]

So my testing with and without pipelining (see above) might be worthless...
additionally I am using a proxy. Of course I pressed Shift-Reload all the time,
but if that works as well as clearing the cache does... :-/

With a new profile clearing cache works. First I loaded the page several times
(with and without shift) using HTTP 1.0 to make sure the correctly display
version is at the proxy.
Then, using a new profile and there using HTTP 1.1 with pipelining, I loaded the
page again, had the error; switched off pipelining: no error.
However, after re-enabling pipelining, clearing the cache and reloading several
times, I coud not reproduce it... weird...
FWIW I a not using a HTTP proxy at all, if that helps any debuggers.
I don't have pipelining enabled, and if I go to the link it looks fine. If I hit
the back button and then go forward to the page it happens every single time.
Reporter, this might be fixed in the latest trunk-version, now that bug 282441
is fixed. Can you test again, please ? The fix will be in the forthcoming
Firefox1.1 alpha.
We updated a javascript component from a vendor which fixed the problem for us.
 Whatever condition the faulty javascript component exposed within Mozilla is no
 verifiable from my end.  Interesting that an updated javascript source file
fixed the problem, perhaps the processed javascript was somehow invalid and
triggered some sort of exceptional condition within Mozilla, I just don't know.
 I cannot say if the bug is fixed or not.  I am sorry that the window of
opportunity to identify any potential Mozilla design flaw is gone in this case.
marking WORKSFORME
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.