When using fixed toolbar in Galaxy Nexus (Android 4.0), the tool bar does not automatically extend to the landscape screen width if the orientation is switched from portrait to landscape
@scottjehl @gseguin @toddparker
Calling all Galaxy Nexus owners. Have you guys discussed a forced reflow on orientation change (or perhaps already implemented it?).
@peterzheng - this is a bug in latest master right? Not just the 1.0.1 release? We'd removed a "width: 100%" rule from the toolbars around that time, but have since added it back as it caused regressions. Can you confirm the bug is in master?
@johnbender: Orientationchange doesn't cause a reflow on its own in that browser?
Do not have the device here. @toddparker?
I haven't any idea, but in retrospect that seems fairly likely :)
@toddparker: Yes, this issue happened after 1.1 RC, 1.0 had no problem.
The issue happened when orientation changes from portrait to landscape, it can be extended to full length when you touch the screen.
It's fine for orientation changed from landscape to portrait.
Sorry, I meant after 1.1RC we removed that commit. The change is here 022d8e5
Can you verify the issue is present on latest? http://jquerymobile.com/test/
@scottjehl: When is this build? I tested on Mar 9's build for RC2, same problem.
@peterzheng - We need you to test on the lastest since Scott said that this was fixed a few days after your test snapshot.
You can test the lastest by including
I just tested again, issue still exist. I verified that 100% width was there, also, the js is the one I got from the link John provided.
It looks like only the fixed tool bar can not get reflowed. I even tried orientation change to force the tool bar's width change, I believe the width was changed (nav element length changed), but the whole tool bar still keep portrait's width -- No reflow happen. Reflow only happened when touch the screen again.
I just tested this page which has fixed toolbars and uses the latest build:
On a Galaxy Nexus running 4.0.1 and cannot reproduce any issues. If I change orientation, the bars re-flow to fit the page width. This seems to be fixed.
@toddparker: There are two differences between my tests from yours: First, I tested it based on real app (hml5+ JQM), not browser based; Second, the new fixed tool does not disappear when I touch the screen in real app, but when I test using browser directly (http://jquerymobile.com/test/docs/toolbars/bars-fixed.html); the screen touch causes the fixed tool bar to disappear. I believe we should use real app to test it. Also, this issue does not exist in 1.01 release.
You'll have to provide us a sample then. http://jsbin.com or http://jsfiddle.net are two good places to do that. Please try and trim the example down to the absolute minimum required to reproduce the issue you're seeing. That'll give us the best shot of addressing the issue.
The follow are steps of reproducing this issue:
You will see the fixed tool bar only shows the portrait's length. Only after you touch the screen, it will be extended to landscape length.
index.html source code:
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta http-equiv="Content-type" content="text/html; charset=utf-8">
<title>PhoneGap Demo With JQuery Mobile</title>
<link rel="stylesheet" href="http://jquerymobile.com/test/css/themes/default/jquery.mobile.css" type="text/css" charset="utf-8" />
<body style="background-color:#000;" >
<div data-role="page" data-theme="a" id="homePage" name="homePage" data-title="Home">
<!-- loginPage -->
<div data-role="header" data-position="fixed" data-theme="a" id="homePageHeader" name="homePageHeader" align="left">
<div data-role="content" data-theme="none" id="homePageContent" name="homePageContent" style="margin-top:0px; padding-top:0px; ">
<div class="content-primary" style="text-align:center;">
</div><!-- contentMain -->
<div data-role="footer" data-position="fixed" id="homePageFooter" name="homePageFooter">
</div> <!-- page1 -->
Thanks for the follow up @peterzheng.
@johnbender - do you have time to give this a look?
I don't have a nexus though I can try and fire up the emulator yes.
Well after firing up the emulator (2 hours later) I can't reproduce this issue in 4.0.3. I'm going to try a 4.0.0 emulator to see if it's reproducible and I'll report back.
No dice on 4.0.0 using the emulator and attached markup :( I'll have to defer to someone with a nexus.
I tried a phonegap application with the fixed toolbar page you posted as a jsbin:
And I get the half way rendered fixed footer and header. Goes away after a touch :(
That tiny little snippet of html will reproduce the issue on 4.0.1, I'm wondering if you can verify:
Bug filled with google. In the meantime here's something entirely horrible that works for me on my Nexus S
We'll keep looking to see if we can find a way to solve this.
Verified http://jsbin.com/ewivap/53, issue exists as expected. http://jsbin.com/ixeyey/55 is working for fixed tool bar, but as you said, we should be careful of using it. Thanks.
Hi all, been wireframing a company project, and haven't got to the point of implementing jQM or any js.
However I have experienced an identical issue on a Xoom running 3.2 (looking at, it has something to do with the position: fixed. On the Xoom clicking the page does indeed extend the bars, but not the content within which remains at the resized portrait size.
No idea on the Nexus, but looking at the jQM site on my SGII running 4.0.3 things appear to behave normally. If anyone needs things looked at on my device give me a shout.
Has any progress been made with this? Thanks.
Just an FYI, I solved this issue using an orientation change but it worked for me. I'm assuming the reason it didn't work for peterzheng is because he set the width to 100%. I had tried that and it didn't work (I think I noticed when inspecting the css for the header that it does have width:100% already on it), then I tried the following and it did work (I only call this if the current page is the problematic one):
Even though it doesn't seem to want to handle the 100% correctly, the screen width pixel size is correct so that will work.
Also, I have a fixed header on a different page of my multipage template, and that fixed header does not have a problem on rotation. I'm running on an iPad2 with 5.1.1 btw... Maybe the solution is to dynamically resize fixed headers to the pixel width of the viewport (although it feels like a bandaid)? I wish I could tell you how to definitively reproduce this. The header I'm having problems with doesn't have a button on the right side, while the page without the problem does. I added a button to the right on header with the problem and that didn't help.
I have a Galaxy Nexus on CM9 (Android ICS v4.0.4). My fixed toolbars extend the full width of the screen in landscape mode. I'm running a custom build of JQM (built with download builder and Latest branch a couple weeks ago). The app is built with Cordova v2.0.
FWIW, this seems to be fixed in stock 4.1.1, both the native browser and Chrome 18.
Sounds like like this issue is fixed in latest so im going to close if anyone is still seeing this problem using the latest code we can reopen.
I still see the issue in a phonegap app. It doesn't happen in the browser, only PhoneGap.
@xdumaine if you are still seeing this can you set up a JSbin according to our contributing guidelines and we will take another look? https://github.com/jquery/jquery-mobile/blob/master/CONTRIBUTING.md
I see this issue in phonegap but not in the browser on Android.
It's basically when you have a
element phonegap doesn't reflow that element. No idea why... It's fine on iPhone.
@sparkio Can you please set up a simple jsbin according to our contributing guidelines and we will take a look at this.
I'm encountering this issue on samsung s3 and galaxy nexus under phonegap (cordova 2.5), I'm able to 'fix' the issue by identifying the offending element in weinre and explicitly setting the max-width of an element far outside of the window bounds(no, there is no css applying a max-width in the app). This sort of behavior doesn't inspire confidence that I won't uncover some much more horrible side effect later, though. Perhaps your development is coupling to emulators which may not be a perfect representation for real world handset performance?