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




DOM: Core & HTML
17 years ago
17 years ago


(Reporter: Jacob Kjome, Assigned: Eric Vaughan)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta3-][rtm need info])


(3 attachments)



17 years ago
I am creating an empty window and piping data to it like this:

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

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 problems:

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:


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


Comment 1

17 years ago
Created attachment 15296 [details]
shows problems with not creating scrollbars on dynamically created javascript windows

Comment 2

17 years ago
this seems to be a regression.  I confirmed it as working in build:

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...


Comment 3

17 years ago
It is still broken in todays build.


Comment 4

17 years ago
just checked newest build 2000092220

still broken.  Please fix this before RTM!!!
Severity: normal → major
Priority: P3 → P2

Comment 5

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


17 years ago
Ever confirmed: true
I see this on linux too, so it appars to be a XP problem...
OS: Windows 2000 → All
Hardware: PC → All

Comment 8

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

Comment 9

17 years ago
Marking nsbeta3-.
Whiteboard: [nsbeta3-]

Comment 10

17 years ago
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!


Comment 11

17 years ago
Re-assignign to Chris Karnaze, the manager of the layout team.
Assignee: nisheeth → karnaze

Comment 12

17 years ago
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'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!


Comment 13

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

Comment 14

17 years ago
Jake, since no url is sited, can you please provide a complete simple test case.

Comment 15

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


Comment 16

17 years ago
Created attachment 16305 [details]
Simplified test case of the previous test case posted to this bug

Comment 17

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

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


Comment 18

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

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

Comment 20

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

oh, d'oh!

Comment 22

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


Comment 23

17 years ago
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
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:
<script type="text/javascript">opener.setChildDocObj(document);</script>

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

After that something like
will work.

For the 2nd problem, this is covered by Bug 55326 and testcase
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 says in his
comment on 2000-09-25 17:10.

Comment 24

17 years ago
Created attachment 16321 [details]
Testcase to check if a childs document object can be used.

Comment 25

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

Comment 26

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


Comment 27

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


Comment 28

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


Comment 29

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

Comment 30

17 years ago
Buster, can you please take a look and assess if we should make this rtm+.
Assignee: karnaze → buster

Comment 31

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

Comment 32

17 years ago
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!!!


Comment 33

17 years ago
this is almost certainly a dup of

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

Comment 34

17 years ago
rtm need info: dup, or common in top 100?
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm need info]

Comment 35

17 years ago
Lest anyone forget my commnets from 9-22:

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

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 

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


Comment 36

17 years ago
This turns out to be a dup.

*** This bug has been marked as a duplicate of 55334 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 37

17 years ago
Verified dupe.
You need to log in before you can comment on or make changes to this bug.