GNOME Bugzilla – Bug 669606
Improve navigation policy in application mode
Last modified: 2017-12-11 23:22:00 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)
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.
*** Bug 680135 has been marked as a duplicate of this bug. ***
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?
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.
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!