I have noticed that when viewing a web page in landscape on an iphone, I get a gap appearing between the navbar and the top of the web page, which is especially annoying when an image is involved. Portrait is OK. iPad seems to be OK on portrait and landscape. If I hide the navbar, the top of the page is at the top of the screen, where it should be. I have tried this with the html doc and html pro plugins, both show the same effect. I am sure it isn't my html and I have run out if ideas, I don't know where to look to fix this problem - any suggestions?

I keep stalling my reply because I don't have a solution. The HTML Doc and the HTML Pro plugins, for the most part, don't do anything new and different to 'display' the data. They just control links and actions and stuff like that. So you're left with the 'WebKit' wrapper that is common to all of those kinds of plugins/displays. And the HTML needs to be compliant for the WebKit 'window'. And you also have the Nav Bar in 2 different sizes depending on orientation (44P/32L). Is the 'gap' about 10 pixels? Therefore, it could be one of two things: 1) the plugin code (or lack of) to accomodate a different size NavBar in Landscape vs Portrait 2) Lack of HTML code to accomodate for the different size NavBar in Landscape vs Portrait. On the other hand, I could be completely off my rocker; All this is just a wild guess on my part... but it's something to chew on... Cheers! -- Smug

10 pixels sounds about right. I think you could be onto something Smug. My HTML test code is pretty basic and is ok for some of the above scenario's - does that point to your 1st theory?

It could be either, actually. It really depends on a point of view, and I could probably argue both sides. But the bottom line would be "fixing it yourself would be the fastest". So I'd find some CSS that would allow me to detect portrait or landscape, and resize the top margin to 0 or -10 depending on the orientation. You could also alter the code of the plugin to resize the window the same way when the orientation changes, I suppose it depends on which is easier for you. Or faster for you. Cheers! -- Smug

Happy to fix it myself if I can, for sure. I've tried the html/css route first, as I am more comfortable there. I reset the margin to a negative value, but it didn't have the desired effect - it just truncated the top of my image. My conclusion is that it appears that the webview is presented in a rectangular area that is 10 pixels below the navbar in landscape. What is inside that rectangular area is OK, but the positioning of the rectangle in landscape on an iPhone is not. Which makes me lean towards your 1st theory again. Not sure why this seems OK on iPad, but I am sure it is a pointer. I'll look inside the code, but I'm pretty poor at programming, so keep an eye out for a question lol!

I think I have found out where the problem is. On the html doc plugin, (and html pro as well), there is a value called browserTop. It is used to set the webview rectangle in the method: -(void)layoutScreen I believe browserTop defines the top of the rectangle used for the webview. I found if I just set it to zero, around line 229, things seem to work as they should. I changed it to look like this: //webView browserTop = 0; // mod applied by Alan, fixes landscape iphone positioning [self.webView setFrame:CGRectMake(0, browserTop, browserWidth, browserHeight)]; There is some logic around how to set the value for browserTop that I can't follow, that seemed to cause the issue. It must be there for a reason, so I am wondering if my mod breaks something else...

It seems like a pretty simple fix to me. I doubt it'll 'break' anything. As long as it updates when the orientation is changed, you "should" be ok. Test and test again. Cheers! -- Smug

If it wasn't simple I wouldn't have worked it out :). Thanks for your help and pointing me in the right direction.

When you do finalize the solution, please send it into Susan for updating on Buzztouch.com She prefers a ready-to-swap file so that she does not have to make any edits. -- Niraj

I have already sent an email to Chris, as the author of the html pro plugin. I'm happy to notify Susan too. From a version control perspective, I think it is better practice to alert the developer and let them finalise the solution and release the update as they see fit. Cheers, Alan

I think this is exactly it, the browser top variable. I'm not even looking at the code and I can remember working that logic out in days gone by. The height of the mouth bar has changed a few pixels over the years in portrait, landscape, I was five, iOS 7 etc. The permanent fix, and I'm not in front of a computer so I can't look at it now, is to use code to calculate the height of the navigation bar which would then be used to determine "browserTop". I hope this makes sense. Like...(psuedo code)... int navBarHeight = self.navigationBar.frame.size.height;

That makes my head hurt

Rotation Issue Fix / Hack / Test: I've re-worked the .h and the .m files for the BT_screen_customURL plugin. Like most of us understand, the layout fixes on this plugin can be carried over to lots of other plugins (WebView based screens) if we like this outcome. I do. I've tested it boatloads tonight - it's 2:00 AM. Three files to play with: 1) http://www.buzztouch.com/test/BT_screen_customURL.h.txt 2) http://www.buzztouch.com/test/BT_screen_customURL.m.txt Remove the .txt at the end of the file name before adding them to your project. These include that extension only so you can download them. Cool webserver's don't like serving up .m and .h files :-). Also, be sure to change the appDelegate name in these two files to match your project. 3) http://www.buzztouch.com/test/map.html Use the map.html page as the dataURL in your config so we're all on the same page. If it works as expected, go ahead and try other URL's. This is a simple html page I created to help us identify if the rat-bastard-driving-us-crazy white stripe show at the top of the HTML content, but below the nav bar. The red box in this HTML webpage (you'll see it) should align directly under the nav bar with zero pixels of space between it and the nav bar. If you set navBarStyle:hidden in your config the red box should be againt the top of the screen. If you rotate to landscapp all should be well. If you change devices (iPad, iPhone5, iPhone6, iPhone6Plus) all should be well. Sometimes removing code is the best solution. This class file is much smaller, much cleaner and far better as far as I'm concerned. Sometimes going back and doing massive housecleaning leaves us with far less fuss. Very true in this case. You'll see how it works. Post comments, we'll go from there...

Hi David, I tried this. It worked fine for me in my test cases, with a couple of points that I thought I'd mention: 1) My html page is in my BT_Docs folder. The android version of this plugin supports accessing the local file using file:///mydirectory/myfile.html syntax. Would it be possible, while you are on a roll, to add similar support for the ios side please? 2) Your test url http://www.buzztouch.com/test/map.html displays the map page on my desktop browser, but not via the custom url plugin in my app test. Thanks, Alan

Regarding the map page. I intentionally used that page to see if it would run the map. My suspicion is your project may not have location services enabled or the two required keys in the P list but I mentioned in a different post yesterday. Regarding the document inside the project, that's not the intention of the. URL plug-in. That's the HTML doc plug-in. Does not mean I couldn't get it to use a local path though, I will look into that :-) While you're at it see if you can get the keys added to the P list so the location manager on that map page works. Not necessarily important for your case but a good idea anyway I think

On my project, you are right on both counts. I will fix the plist in the morning (UK time) and report back. On the local path support, I just thought it would add a bit of flexibility and cross platform compatibility that would really help, so anything you come up with much appreciated. Cheers, Alan

Just modified my exiting plist. Made no other changes and the map html works, as you knew it would. All good. Cheers, Alan. Now for Arsenal to beat Spurs 4:0 !!

Quickie before I finish... Was thinking about the local file URL / Path thing. I'm thinking the Custom URL screen's isn't the place to put this (as I originally thought). Using a local file in the project means the "paths" would have to be the same. Android and iOS use different file paths to local resources (like HTML files). If users entered a "file name" and not a "full file path" it would work - because the app knows the path to the file if it has it's name in iOS or Android, and, the user can use the same file with the same name in both project. We'll just need to get the layout fixes from this URL plugin copied across to the other WebView plugins like Custom HTML, HTML Doc, PDF Doc, etc.

I 100% agree with the ideal that a solution behaves in a similar way across IOS and Android. The problem I picked up with on the file path originates from the issue that I no longer use html doc in Android, because the user experience is so different. So I use custom url in android apps for local html files, but I cannot do that in ios because - well, you know the rest. I guess from from my side I can spot a problem, but not necessarily the best solution.

Just revisiting this. I tried to update my control panel for custom url plug-in, but it didn't go very well and I thought it might be better to wait for the official changes. Any news on that please?