Can you post the bug number that was emailed to you back here as a reference?
Thanks
Rob
It’s Case 33251.
Thanks!
Okay I downloaded your test app. Thanks for providing it. I see what’s going on and I’m talking with engineering about the issue, but basically when it rotates, it adjusts for the moving nav bar by adding width to the content area vs, taking it away from the height so that the one dimension stays 320 the whole time (based on your config.lua). This cause the display.screenOriginX to shift from 0 to -37 (half the height of the nav bar). I got your app to behave the way it should by **adding** the value of display.screenOriginX to all of your .x’s in your webView rotate area. You will probably need to make sure you get everything.
At least you can use this to work around the problem.
Rob
Hi Rob, thanks for looking into it! Could you email me your version of the code, please? I’m not sure if I understood right what you said:
whammy [at] poczta [dot] onet [dot] pl
Nevertheless, engineers should fix the problem on Corona side also, right?
Also - from what you write I’m assuming that you have a margin visible only on the right side (originX shifted to left), while on my tablet I have margins remaining on both sides equally.
Thanks,
@Rob, but isn’t the work-around-solution you’re proposing good only for tablets with android 4 (bottom nav bar appearing), but when I launch the app on a smartphone - the webView with added value would be to wide with some content hidden outside of the screen? :/
First I don’t know that this is a bug. When the nav bar moves, the space it takes up has to come from somewhere. In my case, my Nexus 7 is a 800x1280 screen (1.6 aspect ratio). When you set the content area to 320 x 480 like you are, the screen when scaled becomes 320x512. Take out the space for the nav bar and you send up with 320x482 for your usable content area. When you rotate it, you’re available width is now back to 512 (there are some fractional values here, I’m rounding up for ease of communications).
Because the content area you asked for in this case was 480px, the difference gets padded on the sides, but you told your config.lua that you wanted a 480px wide content area. This causes that 480px to get centered in side the 512px box, in effect letterboxing the sides since you’re only intending on drawing the expected 480px width.
For people who do not use the Ultimate config.lua that you’re using, who use a fixed sized area, they already manage this extra letter boxing by using the values for display.screenOriginX to position things.
This should work on any device because we are going to provide the right value for these items.
Rob
@Rob, you were right - adding the value of display.screenOriginX here and there did the trick. Thanks for your help!
Cheers,
This is not a Corona bug. Your app is using Letterbox scaling mode and using display.actualContentWidth and display.actualContentHeight to fill out the letterbox areas with your assets. Your app is also using the same APIs to center the assets on screen – which is wrong because Corona’s 0,0 reference point is not the edge of the screen but the end of the top left letterbox area. This is why your content is shifted to the right. The proper solution is to either use display.contentWidth and display.contentHeight to center the assets or to add in the letterbox offset using display.screenOriginX and display.screenOriginY to the actualWidth and actualHeight values.
The other issue your app has is trying to dynamically set the Width and Height in config.lua by computing the “aspect ratio” based on display.pixelWidth and display.pixelHeight. As I showed you in your bug case, these values will change on Android devices that resize the tab bar based on orientation (e.g., Nexus 7). With your app I saw the aspect ratio change from 1.7 to 1.5 depending on the startup orientation. This will cause issues when you try to support rotating to different orientations.
Corona does support the resizing on these devices but NOT when you try to dynamically change the Width and Height in config.lua based on your computed aspect ratio. It’s fine to change it based on device types but not based on native pixel sizes on devices where this can change because of startup orientation.
Tom, I was trying to use both actualContentWidth, viewableContentWidth AND actualWidth - all of them drew the same result. Which in my case wasn’t shifting to the right, but drawing margins on both sides while the content was centered.
Regarding a letterbox mode and ‘tricks’ I’m using in config.lua file - I’m just following Rob’s articles (modernising config lua) where the only mode considered in examples was the letterbox mode, so I thought it was a GOOD one 
Adding screenOriginX value did the trick, but IMHO it should be automated during the build. So while it’s not a Corona BUG, maybe, it might be sth worth considering to add in future daily builds.
Anyway, thanks for looking into it.
There are many ways to handle the config.lua. No one setup will work for every condition. In this case, the ultimate config.lua is great for making your content area fit the screen on many different devices but there are conditions like trying to support rotating layouts that it doesn’t work all that well for. I don’t believe that the config.lua gets reprocessed on rotation.
At least we found a way to work around it.
Rob
We’ve talked this over internally and there is nothing we can add to the build that would help you. Android does NOT supply the height of the navigation bar nor does it tell us that the device uses a navigation bar. We only get the screen size based on the device orientation when the device is first started. Those are the numbers we pass along to the app using display.newPixelWidth and display.newPixelHeight. With Android devices that use navigation bars that consume screen real estate, those numbers MAY changed based on app startup orientation.
When you specify letterbox mode, that is based on display.contentWidth and display.contentHeight and the screen origin is adjusted to compensate for the letterbox area. When you use display.actualContentWidth and display.actualContentHeight to position objects, you are bypassing the mode you enabled for positioning your app and need to adjust the location so everything is aligned correctly.
Is it possible to allow us update config? Will that not fix the problem?
Is it possible to allow us update config? Will that not fix the problem?