If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

javascript written to frame instead of being executed

NEW
Unassigned

Status

()

Core
Layout
P3
normal
16 years ago
8 years ago

People

(Reporter: Philip walden, Unassigned)

Tracking

Trunk
HP
HP-UX
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
Created attachment 87991 [details]
Screen dump with affected condition

Note javascript listed in 2 frames at lower left
(Reporter)

Comment 2

16 years ago
Created attachment 87992 [details]
screen dump of screen after resize

After resizing the browser, most of the problem has cleared up. However, the
lower left frame javascript does not operate properly.

Comment 3

16 years ago
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
(Reporter)

Comment 4

16 years ago
Created attachment 88135 [details]
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.

Updated

16 years ago
QA Contact: petersen → amar

Comment 5

16 years ago
> 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

Updated

16 years ago
Component: Parser → Layout

Updated

16 years ago
Priority: -- → P3

Comment 6

15 years ago
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?
(Reporter)

Comment 8

15 years ago
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.

Comment 9

14 years ago
retargeting
Target Milestone: M1 → Future
Target Milestone: Future → M1
Assignee: attinasi → nobody
QA Contact: amar → layout
You need to log in before you can comment on or make changes to this bug.