Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-18195] iOS: Navbar appears to shrink when returning from a window with forced orientation

GitHub Issuen/a
TypeBug
PriorityMedium
StatusClosed
ResolutionWon't Fix
Resolution Date2016-10-19T13:53:27.000+0000
Affected Version/sRelease 3.4.1, Release 3.5.0
Fix Version/sn/a
Componentsn/a
Labelslook1, qe-3.5.0
ReporterEwan Harris
AssigneeHans Knöchel
Created2014-12-12T18:04:10.000+0000
Updated2018-08-02T22:20:02.000+0000

Description

Description

When returning from a window that uses forced orientation, if you are in an orientation that is not supported and return to another window which does not use forced orientation the navbar appears to shrink when you return to protrait mode. Also when returning to the window the icons at the top of the device disappear until you rotate the device too *Note* To 'unshrink' the navbar you just need to simply rotate the device. This *is not* a regression the same occurs in 3.4.1.GA

Steps To Reproduce

1. Using the attached app.js build to an iOS device. 2. Tap the button to open the second window and rotate to an unsupported orientation (in the app.js Titanium.UI.LANDSCAPE_LEFT and Titanium.UI.UPSIDE_PORTRAIT) 3. Tap the button and close the window 4. Go back to portrait

Actual Result

3. The icons at the top of the screen have disappeared 4. The navbar appears 'shrinked'

Expected Result

3. Nothing should be malformed, the icons should appear 4. Nothing should be malformed

Attachments

FileDateSize
app.js2014-12-12T18:06:19.000+00001272
Recording.mov2014-12-12T18:05:37.000+00001510313

Comments

  1. Owen Evans 2015-02-03

    Has there been any progress on this issue? Is it an issues with the Titanium SDK or iOS? Is there currently any way to get around it?
  2. Gregory Hudson 2015-02-13

    Is there any progress in resolving this issue? We have wasted considerable development time and effort in attempting to work around this issue and ultimately had to revert back to using an older version of the Titanium SDK that didn't display this issue. This is not a solution that is viable in the long term as future app submissions to the app store will require 64bit support.
  3. Owen Evans 2015-04-30

    Any progress on this bug? I noticed it was included into a sprint, what was the outcome?
  4. Ingo Muschenetz 2015-04-30

    This should have been moved to the next sprint. It's unclear to me why that didn't happen. I've updated it now so it will be revisited.
  5. Gregory Hudson 2015-06-09

    Has this been allocated to a Sprint yet?
  6. Ivan Skugor 2015-06-10

    Ingo Muschenetz - any update on this?
  7. Ingo Muschenetz 2015-08-12

    [~cng] This should either go in 5.0.0 or 5.0.1. Please take a look.
  8. Ingo Muschenetz 2015-08-12

    Ond second thought, this may be a won't fix. See related tickets.
  9. Tim Poulsen 2015-08-12

    "Forced rotation" is different than what this example shows. In older SDK versions, you could call a method to rotate the window without the user having to rotate the device. (We called that "forced rotation.") This ticket is describing navigating between windows that have differing supported orientations. I think that's different, and should be supported.
  10. Ingo Muschenetz 2015-08-12

    The original window does have a "forced orientation," so this might be an edge case of that particular class of tickets.
  11. Hans Knöchel 2016-10-19

    To get this rolling: The issue is around [this snippet of code](https://github.com/appcelerator/titanium_mobile/blob/master/iphone/Classes/TiRootViewController.m#L1281-L1298) where we are actually transforming the view to match the forced orientation. Again, this won't ever be allowed natively and Apple will very likely reject apps these days because of not following there Human Interface Guidelines. Every solution that could fix this messes up the core by adding even more layout hacks. I'm not sure if we really want this. Finally, I do have a fix that *could* be applied after line 1920: 
        [[UIDevice currentDevice] setValue:NUMINT(target) forKey:@"orientation"];
    It will set the orientation back to the one of the target (which is the portrait orientation in this case). However, although this is not private API usage, this way to set the value is insecure and not future-proof, because it might stop working if Apple ever changes the value of this key (referring to [this post](http://stackoverflow.com/a/26358192/5537752)). So if someone wants to have this behavior anyway, the above snippet is the way to go, but I would suggest to not support it in our SDK.
  12. Eric Merriman 2018-08-02

    Closing old "Won't fix" tickets. If you disagree, please reopen.

JSON Source