Closed Bug 275231 Opened 20 years ago Closed 20 years ago

problem with onresize and document.write()

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Platform:
x86
Other
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: moz, Unassigned)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(1 file)

simple testcase
609 bytes, text/html
Details 
The following cross-btowser script works fine with msie5,6, opera7, nav4,
moz1.2,1.5,1.7, but not with firefox1.0.

The script should change the font-size depending on indow.innerWidth.
(after resizing window font-size shoul change)

<html>
 <head>

  <title>onresize- document.write</title>

  <script type="text/javascript">

  if(window.innerWidth) X= window.innerWidth; //nav4, moz, opera, safari
   else   //msie5
    if(document.documentElement && document.documentElement.offsetWidth)
     X= document.documentElement.offsetWidth;

  document.write( "<style> p {font-size:" + X/10 + "px} <\/style>" );

  onresize= function() { history.go(0) }

  </script>

 </head>
 <body>

  <p>resize the window- font-size should change</p>

 </body>
</html>
Attached file simple testcase — 
Testcase added.
A workaround for this bug is to use
	   onresize= function() { setTimeout("history.go(0)",0 )
instead of onresize= function() { (history.go(0)) }
Keywords: 4xp
Just to keep Firefox 1.0 company, Seamonkey 1.8a6 doesn't change fontsize
either, so Core : something. Events?

(fwiw, IE6 managed two resizes of the testcase, and then went into an
infinite-reload loop until I killed it)
Assignee: firefox → events
Component: General → DOM: Events
Product: Firefox → Core
QA Contact: firefox.general → ian
Version: 1.0 Branch → Trunk
I can not confirm msie6's problems whith the testcase (using XP-SP2).

It worked with moz1.2, 1.5 and (if I remember right) 1.7
We have a bug whith 1.7.5 and 1.8a6

Can anyone confirm this? 
With witch version the bug came up? 
My possibilys to test this are limited, I am user only.
This changed when bug 258917 was fixed.  You can no longer call reload() or
go(0) from inside an onresize handler, since there are no particularly valid
reasons for doing it.

So I'm tempted to mark this invalid.
> This changed when bug 258917 was fixed.  You can no longer call reload() or
> go(0) from inside an onresize handler, since there are no particularly valid
> reasons for doing it.

hmm, the disussion in bug 258917 pointed out old nav4 problems. 
onresize an reload() or history.go(0) may be used in several other situations.

Is it invalid, to chance styles depending on window size? 

I can live whith the workaround described in comment #1, 
but I aggree with comment #46 of bug 258917 (find bar should FLOAT over the 
page).
We have here is a bug and it shold not be unconfirmed (and yes, I know, there 
are a lot of more important bugs).  


> Is it invalid, to chance styles depending on window size? 

No, but there are _much_ better ways of doing it than reloading the whole
document.  You could just change the style, for example.

The find bar was just the last straw.  Far too many sites were reloading the
page _only_ in "Netscape" browsers (including Mozilla) on window resizes in
general, so we decided to disallow it, just like we disallow popup windows. 
Would you say that window.open() not working in an onload handler is a bug?

Yeah, invalid, however unfortunate it is that old Netscape reflow lameness made
it so.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
> > Is it invalid, to chance styles depending on window size? 
> 
> No, but there are _much_ better ways of doing it than reloading the whole
> document.  You could just change the style, for example.

Yes, but this is _one_ way to do it, and widely compatible to other old and
new browsers. (There are much better ways for a lot of things, which mozilla 
supports)

> The find bar was just the last straw.  Far too many sites were reloading the
> page _only_ in "Netscape" browsers (including Mozilla) on window resizes in
> general, so we decided to disallow it, just like we disallow popup windows.

This are good reasons
 
> Would you say that window.open() not working in an onload handler is a bug?

No, I don't. But I feel this here is different.

If it is not fixed for good reasons, resolution should be wontfix, not invalid.

I'm silent now, thanks for your comments.


Is bug 288475 a duplicate of this?
Keywords: testcase
> Is bug 288475 a duplicate of this?

Yes, the same problem. And I don't think it's invalid. It used to work for a
long time (until FF 1.0PR), works in other UAs too and should so in future. 
(The problem might be that even if it will be fixed again in future version, one
cannot be sure that it will work on a user's browser as he/she might use FF 1.0.
So workarounds like location.href=location.href might be the "more safe way")
*** Bug 288475 has been marked as a duplicate of this bug. ***
Daniel, this bug is just like a bug on our popup blocker blocking a popup....
That would be invalid, given that everything is working as planned, no?  So is
this.  The situation is no different -- we're just blocking a known major annoyance.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: