Closed Bug 973498 Opened 11 years ago Closed 10 years ago

Firefox for mobile fires onresize when page is loading

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Version:
27 Branch
Platform:
All
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: lassebrosolatjensen, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36 Steps to reproduce: This simple html page have a onresize function that calls a alert(); function. The onresize funtion get calls when the page loads! http://creativekick.dk/___testing/onresize.html Actual results: This simple html page have a onresize function that calls a alert(); function. The onresize funtion get calls when the page loads! http://creativekick.dk/___testing/onresize.html Expected results: This simple html page have a onresize function that calls a alert(); function. The onresize funtion get calls when the page loads! http://creativekick.dk/___testing/onresize.html
Flags: needinfo?(bugmail.mozilla)
Yeah, is this causing an actual problem? The page should be able to handle resize events.
Flags: needinfo?(bugmail.mozilla)
OS: Windows 8.1 → Android
Hardware: x86_64 → All
What i mean is should window.onresize get called when page is loading? I tested on Samsung Galaxy S3, Android 4.3 with Firefox v. 27
I have done som testing on how I can handle the above issue in my webapplication. And during this problem solving I found that when I run this JavaScript below and stress testing by hitting refresh multiple times I often get the value 980! This is happening on my Samsung Galaxy S3 (360X640) and the same thing is happening on my Samsung Galaxy Tab2 (1280x800)!!! var windowWidth = $(window).width(); alert(windowWidth);
Testing below script on www.browserstack.com in Google Nexus 7 stockbrowser (1280x800)also says 980! var windowWidth = $(window).width(); alert(windowWidth);
Using the below script and getting the value 980 happens also Samsung stockbrowsers and Chrome var windowWidth = $(window).width(); alert(windowWidth);
Using: <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0"> Wil give you the correct $(window).width();
It's hard to tell from your comments but it sounds like our behaviour is consistent with other browsers then. The 980 comes from the default width that mobile browsers use when rendering pages that don't have a meta-viewport tag. See [1] [2] and [3] for more information. [1] http://www.quirksmode.org/mobile/viewports2.html [2] https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag [3] https://developer.apple.com/library/mac/documentation/AppleApplications/Reference/SafariWebContent/UsingtheViewport/UsingtheViewport.html
@Kartikaya Gupta yes I know see "Comment 6". To get back on track :-) The bug(I think it is a bug) I reported is that when a page loads in Firefox Android mobile browser the window.onresize javascript function is getting called. Other mobile browsers only calls the window.onresize function when orientation changes. I tested this script on my Samsung Galaxy S3, Android v. 4.3 and Firefox 27: <!doctype html> <html> <head> <meta charset="utf-8"> <title>Test</title> <script type="text/javascript"> window.onresize = resize; function resize(){ alert("resize event detected!"); } </script> </head> <body> </body> </html>
I agree that this is a *difference* in behaviour from other browsers. I'm not convinced it's a *defect*. Do you have any examples of unexpected negative consequences from this difference in behaviour?
I'm working on a webapplication where I recalculate the page when the user resizes the browser. When the resize function is called while the page is loading it mess up the webapplication. This is my workaround: var windowWidth = $(window).width(); window.onresize = resize; function resize(){ if($(window).width()!=windowWidth){ alert("resize event detected!"); windowWidth = $(window).width(); } }
Sounds like you're going to have the same problem if the device is rotated while the page is loading. How do you deal with that?
No I do not think it is going to be a problem? Why?
(In reply to Lasse2014 from comment #10) > When the resize function is called while the page is > loading it mess up the webapplication. The resize event is fired by a device rotation as well. If your webapplication messes up when the resize function is called during load, it will mess up if you rotate the device during load.
That still happens on Firefox for Android 36. The problem is that when I try to get document.body.clientWidth or document.body.offsetWidth, I keep getting 980. My phone is 360x592. With that approach, I'm not able to assume that the screen size is correct until the page finishes loading. While on other browsers I can start rendering javascript based on screen size, since the beginning of the page load.
(In reply to guivideojob from comment #14) > That still happens on Firefox for Android 36. > The problem is that when I try to get document.body.clientWidth or > document.body.offsetWidth, I keep getting 980. Do you have a meta viewport tag on your page? Note that 980 is the default CSS viewport size for pages without a meta-viewport tag. If you do have a meta-viewport tag, can you attach a test page that demonstrates the problem you're seeing?
Flags: needinfo?(guivideojob)
That's happening in production right now, on one of our products: www.globo.com It reports 980 at first.
Flags: needinfo?(guivideojob)
This jsbin reproduces the error: http://jsbin.com/feditadufo/2 And it has the meta viewport tag.
That sounds like bug 1071620, then. I'm closing this bug as invalid as the original reporter was never able to demonstrate that there was actually a bug here; just a difference in behaviour.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.