Bringing the topic back I've attached the images to the issue https://issues.apache.org/jira/browse/CB-10799
And I want to bring it back because there is a similar issue ( https://issues.apache.org/jira/browse/CB-10796) with a pending PR ( https://github.com/apache/cordova-plugin-statusbar/pull/55) and used hardcoded 20 to fix it. People there is asking me to review, but I don't want to merge it as he is using the hardcoded 20. I think hardcoding to 20 will fix both issues, and listening for the delegate won't, because we need the 20 value even if the statusbar size is 40. 2016-03-10 20:52 GMT+01:00 Shazron <shaz...@gmail.com>: > Apache mailserver has stripped your post of images, so we can't see > anything. My point in listening for that delegate function is so we don't > rely on the hardcoded 20. > > On Thu, Mar 10, 2016 at 7:40 AM, julio cesar sanchez < > jcesarmob...@gmail.com > > wrote: > > > But the problem here is not when the frame changes, is when the toolbar > > used as a fake statusbar is created when the in-call statusbar is > present. > > > > If inAppBrowser is opened with toolbar on top while in-call statusbar is > > present. See the gray bar between in-call statusbar and inAppBrowser > > toolbar. And the webview has 20 points behind the in-call statusbar, > notice > > that the house icon is partially hidden. > > > > [image: Imágenes integradas 10] > > > > And it remains when the in-call statusbar disappears. > > > > [image: Imágenes integradas 9] > > > > If toolbar is at the bottom the only issue is the one I mentioned before, > > the webview has 20 points behind the toolbar (house icon hidden) > > > > [image: Imágenes integradas 7][image: Imágenes integradas 8] > > > > Hardcoding the height of the toolbar used as a fake statusbar to be > always > > 20.0 the problem disappears. > > > > [image: Imágenes integradas 1][image: Imágenes integradas 2][image: > > Imágenes integradas 4][image: Imágenes integradas 3] > > > > > > Listening the statusbar size changes will only solve the problems when > the > > in-call statusbar hides, as the height is 20 again, but when it shows it > > will be 40 and will create the problems mentioned earlier. > > > > > > > > 2016-03-08 2:44 GMT+01:00 Shazron <shaz...@gmail.com>: > > > >> We should leave this be, we can fix and think about it when its > >> actually a problem. > >> > >> Ideally, it should listen to (UIApplicationDelegate): > >> application:willChangeStatusBarFrame: > >> application:didChangeStatusBarFrame: > >> > >> ... for the actual status bar frame changes. > >> > >> > >> On Mon, Mar 7, 2016 at 1:42 AM, julio cesar sanchez > >> <jcesarmob...@gmail.com> wrote: > >> > I've been looking into this issue > >> > https://issues.apache.org/jira/browse/CB-10799 > >> > > >> > The problem is that the inAppBrowser creates a "fake" statusbar using > a > >> > toolbar so the statusbar seems opaque. That toolbar is created with > the > >> > size of the statusbar, and when the in-call statusbar is present it's > 40 > >> > points instead of 20 points, and when the in-call statusbar is > present, > >> the > >> > app is pushed 20 points down so we see the remaining 20 points of that > >> > toolbar. > >> > > >> > Hardcoding it to 20 points in a few places fix the issue, but there > is a > >> > comment on the code > >> > > >> > > >> > *The height of it could be hardcoded as 20 pixels, but that would > assume > >> > that the upcoming releases of iOS won't change that value.* > >> > > >> > So what can we do? hardcode it and hope it doesn't change in the > future? > >> > Any other idea to fix this without hardcoding? > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > >> For additional commands, e-mail: dev-h...@cordova.apache.org > >> > >> > > >
