After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 669606 - Improve navigation policy in application mode
Improve navigation policy in application mode
Status: RESOLVED INCOMPLETE
Product: epiphany
Classification: Core
Component: Web Applications
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
: 680135 (view as bug list)
Depends on: 658395
Blocks:
 
 
Reported: 2012-02-07 21:18 UTC by Giovanni Campagna
Modified: 2017-12-11 23:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Giovanni Campagna 2012-02-07 21:18:29 UTC
Current navigation policy for epiphany --application-mode works well if web site uses plain old <a href=> or <a href= target=>, since those generate link navigation actions, which have a clear current uri and navigated uri, and are results of explicit user actions.
Problems arise when the web site uses more complex navigation methods, such as location.href, <meta http-equiv=refresh> or window.open() - and unfortunately two of the most prominent examples of web applications, GMail and Facebook, do so extensively.

I've tried to come up with a better policy, but didn't get very far, so I'm not attaching the code changes (they're trivial anyway).
In any case what I tried was:
- if in application mode
  - if (it's a link and middle / control clicked)
    or (we have a current origin and
        it's different from the new one and
        the navigated web frame is not an iframe or a _blank)
    - use gtk_show_uri to open a new tab in existing epiphany
  - else
    - return FALSE and navigate the frame normally

Differences from the current policy:
- It allows for an explicit "open in new tab" action, which is useful as a workaround with buggy webapps
- Unless made explicit by the user, it only affects the primary frame, so iframe continue to work
- For the primary frame, it affects all attempts to navigate away, so if the webapp thinks is smarter, we can still recover

Specific improvements:
- Youtube links from Facebook are no longer opened in epiphany (where they don't work, and where there is no back button)

Bugs:
- Left-clicking external links from Facebook results in a white page, because it stops the redirect from happening but doesn't go back to good state (middle-clicking works)
- External links from GMail are unaffected, since they first window.open("") and then navigate the new window, so it firsts compare mail.google.com with NULL (ok), and then NULL with whatever.example.com (ok again)

I hope this report will lead to a positive discussion, whose outcome will be all web apps working correctly, no matter how buggy they are (or how many assumptions they make on the underlying platform)
Comment 1 Jose Dapena Paz 2012-03-16 16:32:04 UTC
Adding dependency on #658395. Both problems are connected, and we need a solution for both:
   * If we are smarter making sure we open in external browser the URI's we'll break authentication when it relies on external services (i.e. Google accounts).
   * If we are less smart, then all external addresses are opened inside web application.

So main problem is we cannot easily make a difference. My proposal is just opening _always_ in the web application window, but showing explicitely that we're browsing an external URI, and showing an action to allow user to open it in browser. Also we show back, so that user can go back to web app.
Comment 2 Alexandre Franke 2012-07-23 21:04:48 UTC
*** Bug 680135 has been marked as a duplicate of this bug. ***
Comment 3 Michael Catanzaro 2017-05-18 15:03:25 UTC
I don't understand this bug report. First of all, is it still valid, or is it obsolete? If there is still a problem, what exactly is the problem, using some public website as an example of how to reproduce the undesired behavior?
Comment 4 Alexandre Franke 2017-05-22 11:32:00 UTC
FWIW links from gmail now open in the default system browser. I have no idea whether that menas that the issue is gone on the epiphany side or whether gmail changed something.
Comment 5 Michael Catanzaro 2017-12-11 23:22:00 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment.
Thanks!