Open Bug 152389 Opened 22 years ago Updated 2 years ago

javascript written to frame instead of being executed

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
HP
HP-UX
Type:
defect

Tracking

()

People

(Reporter: phil_walden, Unassigned)

Details

Attachments

(3 files)

Screen dump with affected condition
68.15 KB, image/gif
Details
screen dump of screen after resize
86.81 KB, image/gif
Details
Requested zip file
14.96 KB, application/octet-stream
Details 
On Mozilla 0.9.9, HP-UX 10.20, older machines,we see pages using multiple frames
displaying the javascript text in the fram and not the result of the javascript
execution. Resizing the window seems to help.

The 0.9.9, HP-UX 11.0 and 102.0 newer machines, do not seem to have this
problem. Perhaps it is user versus kernel threads related, or a race condition?

I don't have access to the html, but I can get a screen dump.
Note javascript listed in 2 frames at lower left
After resizing the browser, most of the problem has cleared up. However, the
lower left frame javascript does not operate properly.
Browser, not Rhino. Reassigning to Layout for now, but we 
need to know more. 

Phil, can you provide a reduced testcase that we can debug?
Without something to step through, we're not going to be able to 
figure this one out.

There are three ways to to provide a testcase involving frames:

1. If it's really small, paste it in the Additional Comments box
   For example:

   Parent page
   <html> 
         etc.

   Frame 1
   <html>
         etc.

2. Provide a URL we can go to

3. Do "Save Page" in Mozilla, zip up the page and folder of
   associated files, and attach the zip file to this bug -
Assignee: nboyd → attinasi
Component: Core → Layout
Product: Rhino → Browser
QA Contact: pschwartau → petersen
Target Milestone: --- → M1
Attached file Requested zip file — 
looking at some of the attached pages, the javascript showing up is indeed
because there is a spurious </script> tag before the aoffending script shows in
the frame. All I can say is that the same application renders properly on other
machines and resizes seem to help somewhat. I do not know how the view "page
source" is stored, whetehr it is saved directly from the stream or whether it
is regenerated from internal memory structures. If the latter, then maybe there
is a timing issue.

Notes from the affected user...

Brian,

Mozilla on mysnake saves nothing but empty directories when I try to
save the whole page.  No error messages, nada.

I was able to capture the overall page and some of the individual frames
individually (attached).  The
emxLoadEngineeringCentralProperties.jsp.html file seems to be the page,
and the two problem frames (full of java goop) are
emxengchgBasicSearch.jsp.html and emxengchgHandlerFrame.jsp.html.  The
other two are the top area stuff and the main lower left area.	

It looks like there are a couple more frames called for, but I couldn't
figure out how to get them to save.

Tom.
QA Contact: petersen → amar
> Looking at some of the attached pages, the JavaScript showing up
> is indeed because there is a spurious </script> tag before the
> offending script shows in the frame. All I can say is that the same 
> application renders properly on other machines and resizes seem to
> help somewhat. 


Thanks, I also see extra tags in the attached zip file, although
I do not know if this was somehow caused by the Page Source problems
or Save Page problems you mention above.

Yes, an extra <script> or </script> tag will have unexpected 
consequences. Also note that in Mozilla, malformed HTML comments
will cause JavaScript to show unintentially. For example, see
bug 106162 "JavaScript code processed as plain text", where 
this was the cause. See particularly Comment_ #9 and #10.

I'm not sure whether this is a valid bug or not; if a page has 
malformed HTML, there's not too much we can do about it.

Note there are HTML validators catch mistakes like this; see 
http://validator.w3.org/  or http://www.htmlhelp.com/tools/validator/

I would mark this one as Invalid, except I'm curious why a resize 
would "fix" things. That's the one part I don't understand.
Component: Layout → Parser
Component: Parser → Layout
Priority: -- → P3
10.20 is single threaded (no pthreads) whereas 11.00 uses pthread
Could this be a threading issue (multiple frames) that points to
a timing/race condition???
Is this still a problem?
As far as I know it is. I personally cannot duplicate it as my hardware does not
exhibit the problem. The original reporter in my company is no longer available.
retargeting
Target Milestone: M1 → Future
Target Milestone: Future → M1
Assignee: attinasi → nobody
QA Contact: amar → layout
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: