Closed Bug 146143 Opened 22 years ago Closed 22 years ago

document.write() not executed on 'Back' after full-page plugin like Acrobat

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.1beta

People

(Reporter: sroddsson, Assigned: jst)

References

Details

(Keywords: regression, testcase, Whiteboard: [ADT2 RTM] [fix on trunk] [ETA 07/16][verified-trunk])

Attachments

(2 files, 1 obsolete file)

Test case
390 bytes, text/html
Details
This should fix this problem w/o the regressions introduced by the above diff
3.56 KB, patch
bzbarsky
: review+
jag+mozilla
: superreview+
chofmann
: approval+
Details | Diff | Splinter Review 
JavaScript is not executed when coming back to a page that linked a PDF document.

Steps to reproduce:
1. View a page containing JavaScript and a link to a PDF document
2. Click the pdf document link
3. Click Back on the browser
4. The JavaScript is not executed

Using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0+) Gecko/20020521
and Acrobat Reader 5.0.5

Attaching a HTML file which reproduces this.

Not sure which component this belongs to. Unable to find a dupe.
Attached file Test case — 
Test case as promised.
-> Plugins (?)
Assignee: Matti → beppe
Component: Browser-General → Plug-ins
QA Contact: imajes-qa → shrir
->testcase ?
Keywords: testcase
Whiteboard: [adobe]
tested this using the branch bits from 20020523 on win98. I am able to reproduce
this easily. I created two other testcases, one linking to a full-page image,
and the js executed as expected. I also tested linking to an ftp url, and the js
executed correctly.

I am unclear as to whether this is a js issue or a plug-in issue. Handing over
to av for review and cc'ing jband and jst for input
Severity: normal → major
Priority: -- → P3
Whiteboard: [adobe]
Target Milestone: --- → mozilla1.1beta
to av
Assignee: beppe → av
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is a regression! This WFM on WinXP/Win2k/Win98 on the official NS 7 beta
bits but fails on Gecko/20020520 commercial branch (tested Win2k/Win98/OSX).

Shrir, would it be possible to narrow down the day this happened?
Keywords: regression
will do...
caused between 0517 and 0518 checkins.
I have a feeling it is this checkin :
http://bugzilla.mozilla.org/show_bug.cgi?id=143853

here is the chekins list during that period:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaBranchTinder
boxAll&branch=MOZILLA_1_0_0_BRANCH&branchtype=match&dir=&file=&filetype=match&wh
o=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=05%2F17%2F2002+00%3A0
0%3A00&maxdate=05%2F18%2F2002+00%3A00%3A00&cvsroot=%2Fcvsroot
fix for bug 143853 does not regress this,
I've tried bypass that code in debugger, nothing changes.

 
I don't think this is a plugin bug, but feel free to bounce back.

--->reassign to Javascript Engine
Assignee: av → rogerl
Component: Plug-ins → JavaScript Engine
Keywords: nsbeta1
QA Contact: shrir → pschwartau
Summary: JavaScript not executed on back after Acrobat → JavaScript not executed on back after full-page plugin like Acrobat
Here is the heart of the testcase from Comment #1:

<body>
  <script> document.write('Hello world');</script>  
  <a href= etc.><br>PDF Document</a>
</body>


Just as reported above:

1. When you first load the test, you see 'Hello world' at the top
   and the link below it. 
2. Click on the link: the PDF file opens within the Mozilla window
3. Click the 'Back' button of the browser
4. You are back at the original page, but now you only see the link.
   There is a blank line above it, but no 'Hello world'.


Stepping through this in the JS Debugger shows that the document.write()
line is definitely accessed when we hit the 'Back' button, but it produces
no visual output in the browser for some reason.

If I replace the document.write() with an alert() instead, I do get
the alert both on initial load and after hitting the 'Back' button.

I also tried this in the <script>: |window.status = new Date().toString()|.
This successfully updates the status bar after hitting the 'Back' button.

So it's not a problem of the JavaScript not firing; it is a problem 
specific to document.write(). Shrirang noted in Comment #8 that this
seems to have regressed between the 0517 and 0518 checkins.

Reassigning to DOM Level 0 -
Assignee: rogerl → jst
Component: JavaScript Engine → DOM Level 0
QA Contact: pschwartau → desale
Summary: JavaScript not executed on back after full-page plugin like Acrobat → document.write() not executed on 'Back' after full-page plugin like Acrobat
This will "fix" the problem until we get our fullpage plugin story into better
shape, once that's done there will always be a document in a window and this
code would work w/o this change.
Status: NEW → ASSIGNED
OS: Windows 2000 → All
Hardware: PC → All
Whiteboard: [HAVE FIX]
I guess it wasn't made clear earlier what the reason was for this problem... The
reason mozilla was behaving the way it was behaving was that fullpage plugins
don't have a document object, so window.document would be null when a fullpage
plugin is loaded. When going back from a fullpage plugin to a normal document we
failed to properly update the cached window.document property so window.document
remained null in the page we went back/forward to. The fix is to always make
sure the cached window.document property is updated on page transitions, even if
there was no document in the window we're leaving.

bz, r=?
Comment on attachment 87693 [details] [diff] [review]
Proposed fix, make sure the cached property window.document is always up to date.

r=bzbarsky, but change the 

  // If we didn't clear the scope (i.e. the old document was		        
  // about:blank)

comment a few lines lower to mention full-page plugins too?
Attachment #87693 - Flags: review+
Comment on attachment 87693 [details] [diff] [review]
Proposed fix, make sure the cached property window.document is always up to date.

sr=jag
Attachment #87693 - Flags: superreview+
Attachment #87693 - Flags: needs-work+
Comment on attachment 87693 [details] [diff] [review]
Proposed fix, make sure the cached property window.document is always up to date.

jst is working on doing this better.
Attachment #87693 - Attachment is obsolete: true
Should, or have you made sure?
*** Bug 153916 has been marked as a duplicate of this bug. ***
As far as I can tell this is a safe fix for this problem.
Comment on attachment 88742 [details] [diff] [review]
This should fix this problem w/o the regressions introduced by the above diff

r=bzbarsky, for real this time... ;)
Attachment #88742 - Flags: review+
Comment on attachment 88742 [details] [diff] [review]
This should fix this problem w/o the regressions introduced by the above diff

sr=jag
Attachment #88742 - Flags: superreview+
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
nominating for the 1.0 branch. This is highly visible -- I ran into this several
times today.
Keywords: adt1.0.1, mozilla1.0.1
Whiteboard: [HAVE FIX] → fix on trunk]
Blocks: 153767
desale, can you verify this fix on the trunk.  thx.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: fix on trunk] → fix on trunk] [eta=7/15]
Blocks: 143047
Whiteboard: fix on trunk] [eta=7/15] → [ADT2 RTM] [fix on trunk] [ETA 07/13]
shrir - any word on the verification for this fix?
verifying on desale's part... 

this fix look great on 0712 trunk. Js executes fine now.
Status: RESOLVED → VERIFIED
Whiteboard: [ADT2 RTM] [fix on trunk] [ETA 07/13] → [ADT2 RTM] [fix on trunk] [ETA 07/13][verified-trunk]
Sorry for getting back to this one late.
Yes, This one is fixed on trunk.
Thanks shrirang for covering this one.
adding adt1.0.1+.  Please get drivers approval before checking into the branch.
Keywords: adt1.0.1 → adt1.0.1+
Comment on attachment 88742 [details] [diff] [review]
This should fix this problem w/o the regressions introduced by the above diff

a=chofmann for 1.0.1  add the fixed1.0.1 keyword after checking into the
branch.
Attachment #88742 - Flags: approval+
Keywords: mozilla1.0.1 → mozilla1.0.1+
Whiteboard: [ADT2 RTM] [fix on trunk] [ETA 07/13][verified-trunk] → [ADT2 RTM] [fix on trunk] [ETA 07/16][verified-trunk]
checked in on the branch
Keywords: mozilla1.0.1+ → fixed1.0.1
verified on branch 2002-07-17-08-1.0
Keywords: fixed1.0.1 → verified1.0.1
*** Bug 186215 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: