m.here.com doesn’t close authentication page after logging in

[Dave Morley]

STEPS:
1. Open the browser
2. Goto m.here.com
3. Click on the grid top right of the page
4. Click on sign in
5. This now opens a new tab for the sso auth
6. This tab isn't closed
7. Click on the option menu show tabs
8. Click on the here maps tab
9. Note you are now logged in.

Repeat the steps in the here maps app, now you can't select tabs so although you are now logged in you can't get to a point where you can't get back to the maps.

[Olivier Tilloy (osomon)]

So the issue, in the browser app, is that the tab that opens for authentication doesn’t automatically close itself when authenticated.
Not sure what the behaviour is in the webapp container, as I don’t have the maps app handy.

[Dave Morley (davmor2)]

Oliver so currently the app does exactly the same as the browser only you obviously don't have the option to switch tabs so you are stuck on the blank login page

[Olivier Tilloy (osomon)]

The issue probably is that oxide doesn’t notify the browser that a window/tab requested to be closed (through a JS call to window.close()), and therefore the tab is not closed.

[Olivier Tilloy (osomon)]

Implementation of the corresponding API in oxide is being tracked by bug #1321969.

[Chris Coulson (chrisccoulson)]

Should we just duplicate these bugs and add a webbrowser-app task to the other one? Note, that bug 1321969 isn't entirely related - theoretically adding an API to handle properly closing a webview (bug 1321969) and adding support for window.close() (this) are separate issues, but there is so much overlap between them that I'm treating them as a single task

[Olivier Tilloy (osomon)]

I kept them as two separate bugs because it wouldn’t be immediately obvious from the title and summary of bug #1321969 that the lack of such an API is causing the issue described here.

Once bug #1321969 is fixed in oxide, we can fix this one in webbrowser-app.

[David Barth (dbarth)]

For reference, the plan is to fix the problem in an override specific to the her maps webapp.
Which lowers the requirement to fix the bug in oxide as a pre-requisite.

[Olli Ries (ories)]

please resubmit with a fix attached for new assessment

[Olivier Tilloy (osomon)]

The browser (in vivid) now honours Window.close() requests. However logging in to here.com still fails (it actually fails even earlier than it used to, the tab isn’t closed but the user isn’t logged in either). Let’s keep this bug open for now.

[Olivier Tilloy (osomon)]

I just looked into this issue further, and the login page consists of a form with the following code:

    <form id="hereSignInForm" method="post" name="signInForm" action="HEREAccount_logincallback.php" onsubmit="return false;">
        […]
        <div class="modal-button-row">
            <button id="signInBtn" class="call-to-action primary" type="submit" tabindex="4">
                <span>Sign in</span>
            </button>
        </div>
    </form>

The 'onsubmit="return false;"' guarantees that the form will never be submitted. It seems like plainly broken code on here.com’s side. I verified that I’m getting the same code on chrome on android, so login doesn’t work there either.
I’m now going to mark this bug fixed, as the original issue (the authentication page not closing) should be fixed.

[David Barth (dbarth)]

Further to that, Alex is on a branch to host the login popup in a dedicated
webview overlay, which should solve navigation problems related to the
login process.

On Wed, Feb 18, 2015 at 12:23 PM, Olivier Tilloy <
<email address hidden>> wrote:

> I just looked into this issue further, and the login page consists of a
> form with the following code:
>
> <form id="hereSignInForm" method="post" name="signInForm"
> action="HEREAccount_logincallback.php" onsubmit="return false;">
> […]
> <div class="modal-button-row">
> <button id="signInBtn" class="call-to-action primary"
> type="submit" tabindex="4">
> <span>Sign in</span>
> </button>
> </div>
> </form>
>
> The 'onsubmit="return false;"' guarantees that the form will never be
> submitted. It seems like plainly broken code on here.com’s side. I
> verified that I’m getting the same code on chrome on android, so login
> doesn’t work there either.
> I’m now going to mark this bug fixed, as the original issue (the
> authentication page not closing) should be fixed.
>
> ** Changed in: webbrowser-app (Ubuntu)
> Status: Confirmed => Fix Released
>
> ** Changed in: webbrowser-app
> Status: Confirmed => Fix Released
>
> --
> You received this bug notification because you are a member of Ubuntu
> WebApps bug tracking, which is subscribed to webbrowser-app.
> https://bugs.launchpad.net/bugs/1353453
>
> Title:
> m.here.com doesn’t close authentication page after logging in
>
> Status in Web Browser App:
> Fix Released
> Status in webbrowser-app package in Ubuntu:
> Fix Released
> Status in webbrowser-app package in Ubuntu RTM:
> Confirmed
>
> Bug description:
> STEPS:
> 1. Open the browser
> 2. Goto m.here.com
> 3. Click on the grid top right of the page
> 4. Click on sign in
> 5. This now opens a new tab for the sso auth
> 6. This tab isn't closed
> 7. Click on the option menu show tabs
> 8. Click on the here maps tab
> 9. Note you are now logged in.
>
> Repeat the steps in the here maps app, now you can't select tabs so
> although you are now logged in you can't get to a point where you
> can't get back to the maps.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/webbrowser-app/+bug/1353453/+subscriptions
>
> --
> Mailing list: https://launchpad.net/~ubuntu-webapps-bugs
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~ubuntu-webapps-bugs
> More help : https://help.launchpad.net/ListHelp
>