Child Item

Padding around elements in /oauth2/authorize login UI

Is there any way to get the oauth2/authorize page to put padding around the login UI?

My app's UI looks like this (I'm not using the iOS SDKs, I'm using the REST API directly, so that I can present the auth interface in a custom way):

The popover contains a plain UIWebView. However wide I make the popover / webview, the email and password fields size to fit the width and the "sign in" button right-aligns without any padding, so they end up hard against the edges. Is this by design?

Find more posts tagged with

API

Abuse

Comments

Greg-DB

Thanks for writing this up Olive! The formatting on this page is a known issue we'll fix on our side.

Olive T.

Thanks Gregory, that's good to hear!

Olive T.

Hi Gregory,

What's the timescale for fixing this? We are considering reverting to v1 API in the meantime.

Greg-DB

Apologies for not following up on this thread, Olive! This should already be fixed. Are you still seeing this?

(This may work differently in your app of course since you're not using the SDK, so if you are still seeing an issue, please supply a screenshot showing the current state of the page in your app.)

Olive T.

Thanks, Gregory. Unfortunately it's actually even worse now -- the button is no longer entirely onscreen:

This problem exists on an iPad 2 (non-retina) or iPad Air (retina). Strangely enough, on an iPad Pro, it's okay, but only if the iPad Pro is running at non-native resolution, i.e. emulating the screen size of an iPad Air; if the iPad Air is at native resolution, the problem persists. Hopefully this information can help you to track down the fix!

Greg-DB

Do you know what the User-Agent for your UIWebView is? It looks like you're actually getting the desktop version of this page (which isn't fitting in that narrow UIWebView).

Olive T.

User-Agent is unchanged from the default. Here's how it looks when run on the iPad simulator (on which the issue is also present):

Mozilla/5.0 (iPad; CPU OS 9_3 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Mobile/13E230

Olive T.

But yes, if I make the popover the whole width of the device's screen, it does look as though I'm getting the desktop version:

Olive T.

(NB the same User-Agent works fine with the v1 SDK's special "/1/connect_login" endpoint.)

Greg-DB

Thanks for the additional information Olive, that's helpful.

Based on your original screenshot too, it looks like you were always getting the desktop version of this page, but this issue just arose due to some styling changes.

I'm reporting this to the team, but I can't make any promises for a fix right now. If you have a screenshot of what it looked like before the issues though, and if you could let me know the current width of your popover browser, that may be helpful for reference.

If you can easily increase the width of that popover in your app though, that may be a easier/faster fix for now.

Olive T.

This is what it used to look like:

I say "it", but "it" is a different thing to the "it" from before: here, it's the "/1/connect_login" endpoint from the v1 API, whereas further above, it's the "/oauth2/authorize" endpoint from the v2 API.

I've just realised something else: on iPhone it looks fine, albeit different from the v1 endpoint styling:

Are you serving different pages to the iPad and iPhone, on the basis that the iPad's screen is wide enough to show the desktop version, and that the iOS SDK presents the login page in a modal form view?

If so, please ask your team to change that. It's tempting to think that the User-Agent gives you information about the context in which the page will be displayed, but that's not the case. It used to be that you could assume fullscreen presentation on an iPad, but that's no longer true: modern iPads can now run different apps split-screen. You now need to take a "responsive" approach, i.e. layout differently according to the width of the browser "window": the "desktop" version of the page should reflow to a compact layout when the user resizes their "desktop" browser window below a certain width, and there should be no "mobile version" of the page.

Greg-DB

I see, thank you for the additional information and screenshots! I'm including it in the report with the team.

Olive T.

Sorry, I forgot to mention: the width of the webview is 320pts in both cases (the popover on the iPad and the fullscreen modal presentation on the iPhone).

Olive T.

Okay, I've now confirmed that I can make it work on the iPad by pretending to be an iPhone:

Hopefully the team will fix this anyway. On a related note, why is the QuickSearch icon not displayed on the new "mobile" page, as it is on the old "mobile" page and the "desktop" page?

Coma

Kalsoomdanish

Gulalai Khan Khan