Closed Bug 53683 Opened 24 years ago Closed 24 years ago

scrollbars=yes ignored on window.open when opening blank document and then dynamically writing to it via javascript "with" statement

Categories

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

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

Tracking

()

Status:
VERIFIED DUPLICATE of bug 55334

People

(Reporter: jrspm, Assigned: eric)

Details

(Keywords: regression, Whiteboard: [nsbeta3-][rtm need info])

Attachments

(3 files)

shows problems with not creating scrollbars on dynamically created javascript windows
4.45 KB, text/html
Details
Simplified test case of the previous test case posted to this bug
844 bytes, text/html
Details
Testcase to check if a childs document object can be used.
632 bytes, text/html
Details 
I am creating an empty window and piping data to it like this:

linkswin = window.open('','','scrollbars=yes,width=600,height=400');
  
  with (linkswin.document) {
  	open();
  	write(myheader + mytext + myfooter);
  	close();
  }

The resulting text in the window requires a vertical scrollbar to be there to 
see it all.  however, even though I specified 'scrollbars=yes', no scrollbar 
shows up.  This is not the case if I just load an existing document from a URL 
into the window.  In that case, the scrollbars appear as they should.

see a related by that I reported also related to window.open problems:

http://bugzilla.mozilla.org/show_bug.cgi?id=53343

There is also another bug out there where if you view the source of a window 
created dynamically like I showed above and view source, all you see is:

'<html><body></body></html>'

I am attaching a test case right after I report this bug.


Jake
this seems to be a regression.  I confirmed it as working in build:
2000091505

So, on Friday, September 15th 2000, this worked just fine.  Scrollbars are 
shown just as should be expected.

I'll test in today's build to see if it is still broken...

Jake
It is still broken in todays build.

Jake
just checked newest build 2000092220

still broken.  Please fix this before RTM!!!
Severity: normal → major
Priority: P3 → P2
Sorry for the spam, but still broken in build 2000092308
Priority: P2 → P1
Dan, any ideas about this? (adding a bunch of keywords)
Assignee: jst → danm
Keywords: 4xp, correctness, nsbeta3, regression, rtm
Status: UNCONFIRMED → NEW
Ever confirmed: true
I see this on linux too, so it appars to be a XP problem...
OS: Windows 2000 → All
Hardware: PC → All
  Well, scrollbars=yes of course does nothing in Mozilla -- it's the default 
condition. scrollbars=no turns into flags that effectively propagate an 
overflow:hidden style into the content docshell. I watched the test case load, 
and never noticed a scroll style of anything but the normal, default case being 
applied to the docshell.
  In fact, the HTMLContentSink is creating a scrollframe. Everything seems normal 
here. So I'm guessing something in layout isn't realizing its contents have been 
resized when JS writes to the document. Punting to the layout guys. Guessing 
Nisheeth for now.
Assignee: danm → nisheeth
Marking nsbeta3-.
Whiteboard: [nsbeta3-]
I don't see why this can't be fixed.  I already commented on the fact that it 
was working in build 2000091505.  

Just take the code that calculates how the scrollbars should be there and 
replace the regressed code.  Maybe I'm oversimplifying this, but this is a 
problem I am going to see every day since I use a script very similar to the 
attachment on my web pages to display a list of links that exist on any 
particular page on my site.

Please fix this for RTM!

Jake
Re-assignign to Chris Karnaze, the manager of the layout team.
Assignee: nisheeth → karnaze
In todays build (Mozilla M18 builds) 2000100308 it opens a blank window.  It 
doesn't even attempt to write the dynamic data to the new window.  So, until 
that is fixed, we can put off even considering getting back scrollbars.  There 
is no data to scroll now.

Also, if you look at the behavior of regular window.open's, it looks like it 
loads, not literally but in essence, an about:blank document with the default 
gray-blue background and then it loads the new page.

Really, this stuff needs to work for RTM!

Jake
The observation above works for me with a very recent build. (Which is not to say 
that this bug works for me; only the observation above.) Jake is probably 
referring to bug 55275, whch has been fixed.

Jake, since no url is sited, can you please provide a complete simple test case.
What do you mean by recent build? I test with the newest available build on the 
M18 branch every day.

I'll have to wait until that fix make it into an available build for testing 
tomorrow to see if the blank window thing is fixed.

If by some miracle the scrollbars work on the dynamically created document, we 
can mark this as "works for me". I doubt it.

I'll try to create a simplified test case in the meantime that should work once 
we get a build with the fix from bug 55275

Jake
The test case I just posted was tested and shown to work in IE5.5 and Netscape 
Navigator 4.75.  It just writes more text than can fit in the current viewport 
forcing a vertical scrollbar.  However, in Mozilla, no scrollbar is provided, 
even though you can use the arrow keys to scroll up and down the document.

Note: todays build 2000100504 M18 branch still pops up a blank window.  This is 
supposed to have been fixed and should work in tomorrows build, hopefully.  
Only then can my testcases be viewed with Mozilla.

BTW, I tried viewing the source of the blank window.  It displayed 
<html><body></body></html>

Then, I close the view source window and Mozilla crashed.  I'll check if this 
bug has already been reported.  Anyone seen this bug?

Jake
Ok, I found the close view source crasher bug.  It is bug 53953.  I created an 
attachment moderately similar to the one I posted here and it generates the 
problem 100% of the time on todays build.

Jake
The reason for the window coming up blank in current mozilla builds is the
problem reported as bug 55275.

yep, danm already saw that and I referenced that about two comments after he 
mentioned it.

Jake
oh, d'oh!

Ok, the good news is that the new build doesn't have the blank window problem 
anymore.  The bad news is that there are now two issues.

1. window won't open until a toolbar button is moused over: bug 55032

2. still no scrollbars on either test case

The first test case seems to scroll with the keyboard arrow keys.  Can't tell 
in the second testcase becuse all the text is exactly the same.

Jake
There's currently 3 issues covered by this bug:
1. Javascript can't access the document object of a child window.
2. Scrollbars do not appear where necessary when the content is generated by
Javascript.
3. Even when there are no scrollbars, you can still move up and down using the
keyboard.  However, you can only do this when scrollbars=yes is present.  If it
is not present you can't scroll.

While the 3 problems are related, it is possible to seperate them.

For the 1st problem, I'm going to attach a testcase after this comment.
There is a work around for this:  The new window can access its own document object.
You can use this to completely work around the problem :
Create a new child window, with the url set to an html file that is something like:
<HTML><body>
<script type="text/javascript">opener.setChildDocObj(document);</script>
</body></html>

You'll need something like the following javascript in the html of your main window:
  var childDocObj;
  function setChildDocObj(in_childDocObj)
  {
    childDocObj=in_childDocObj;
  }

After that something like
  childDocObj.write("Hello");
will work.

For the 2nd problem, this is covered by Bug 55326 and testcase
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=16224
tests for this.

I only spotted the 3rd issue when I was researching the other two.  This
behaviour is the same as if scrollbars=no had been specified.  It maybe that the
default for scrollbars is no, which is not what danm@netscape.com says in his
comment on 2000-09-25 17:10.

Just tested this bug in build 2000100520 in NT.
The problem of not being able to access a childs document object is fixed.
The testcase of 10/05/00 21:13 now writes text to the new window.
Still no scrollbars still.

Conor, I'm curious.  Are you able to use either of my attachments to pop up a 
new window without having to mouse over the toolbars?

You didn't seem to mention that.  That is still kind of a big issue in itself.  
It doesn't seem to matter on your attachment where you popped up the new window 
without user interaction, but when the user makes the call to the function by 
clicking on the link, no window appears until you mouseover the toolbar buttons.

Jake
If I click on the link to open a new window in either of your attachments, and
leave the mouse where it is (over the link) the new window opens (it takes a few
seconds for some reason).
I don't move the mouse over the toolbars in the main window.


Try opening and closing the new window a couple of times.  It actually behaved 
as you just stated the first time I tried it, but subsequent times took longer 
and longer to open the new window and eventually, I had to mouse over the 
toolbar buttons to force the window.

Either way, it is taking far longer than normal and far longer than build 
2000091505 ever took which, btw, was the last build I know of that works with 
both of my testcases.  It has scrollbars and everything + the window pops up 
immediately.

Jake
Does take a long time sometimes.
Haven't really noticed mousing over the toolbars bringing up the new window
quicker, but given that it takes varying times to bring it up its hard for me to
determine if there is a relationship there.

Buster, can you please take a look and assess if we should make this rtm+.
Assignee: karnaze → buster
Looking at the testcases of 9/21 and 10/05 in Build 2000101020 in WinNT.
The New Windows are opening in a timely manner, with no delay.

Yep, I saw the see the same thing, however they act, first, like they are 
painting full size window and then trimming it down because, initially, you see 
the edges of a larger window which is then downsized to the size that was set 
for the window.

However, the issue still stands that no scrollbars are being generated.  bug 
55334 get's more directly at this isssue since it talks more specifically about 
no scrollbars being created with javascript generated content without talk of 
new windows.

This bug and bug 55334 affect Chatzilla since that client now has no scrollbars 
in the chat pane.  See bug 56064

Please do fix this for RTM!!!

Jake
this is almost certainly a dup of http://bugzilla.mozilla.org/show_bug.cgi?id=55334

As jst and I already commented in that bug, we think it's a serious problem that
can make pages unusable.  It should be examined for rtm, and if the fix is small
and safe, it should be allowed.

I'll let eric actually decide if this is a dup or not.
Assignee: buster → evaughan
rtm need info: dup, or common in top 100?
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm need info]
Lest anyone forget my commnets from 9-22:

"this seems to be a regression.  I confirmed it as working in build:
2000091505"

It just seems like someone can figure out why it is working there and make the 
changes needed to make it work in Trunk builds and RTM.

Also, I'm not sure that you will find this problem on the top 100 sites, since 
most of those are pretty conservative with javascript.  However, it is going to 
piss off a TON of web developer who have been waiting for Netscape to come out 
with a DHTML capable browser.  If the developers don't like your browser, all 
the sites will continue to be pretty slanted toward proprietary IE 
functionality.

I think that is all the reason you need to fix this!

Jake

This turns out to be a dup.

*** This bug has been marked as a duplicate of 55334 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Verified dupe.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: