Search in address bar is redirecting to website's search plugin

[avinashbharti97]

Subject of the Issue
On visiting https://www.sugarlabs.org using Browse-activity and then using the Address bar if any keyword search is performed then the address redirects to website's search plugin instead of normal google search.

Test Environment

• Sucrose on ubuntu 18.04

Steps to reproduce

• Open Browse-activity
• visit https://www.sugarlabs.org
• Try to search any keyword using address bar of the browse activity

Expected Behaviour

• On searching any keyword from address bar it should redirect to google search

Actual Behaviour

• Keyword search redirects to website's search plugin.

[quozl]

Isn't this how it was designed and always worked? Why is that behaviour not expected?

[avinashbharti97]

Providing link manually in the address bar also leads to website's search plugin.
This behavior is not only limited to keywords but links also :) .

[quozl]

I'm waiting for https://sugarlabs.org/ to return to normal service before I test this, but I think this behaviour is normal and expected for the Browse activity.

[avinashbharti97]

If this behavior is normal then I would not like this issue to be tested. I did a wrong analyse of UX, So I am closing this issue 😊
Thanks

[quozl]

I want my opinion tested. Is it coded to do this, or is it accidental? If it is not coded, why is it happening?

[rhl-bthr]

This was discussed in #78 (comment) and further comments

[quozl]

I see, thanks. Good memory. Mine was vague. @avinashbharti97, are you testing with the latest commit in Browse, or with a pre-installed Browse activity from Ubuntu 18.04?

[avinashbharti97]

Yes, I am testing with the latest commit.
Though both the previous and current issue looks same but I think both are different, Once sugarlabs.org will be live I will test this thoroughly and explain the behaviour again.

[quozl]

Good, thanks. I'm also waiting for https://sugarlabs.org/ to return to normal service before I test this. If you know of another web site that triggers the behaviour, let me know.

[tony37]

What is expected behavior of Browse when not connected to the internet, e.g. to a local server? With internet service available here, any reference to Google can cause a delay of minutes.

[quozl]

Tested Browse-157.4 on Fedora 18, and Browse-202 on Ubuntu 18.04. Behaviour as discussed above does reproduce in both cases;

• visit https://sugarlabs.org/ and wait for page to finish loading,
• click in the URL entry; the URL is selected,
• type a search term; the URL is erased and the entry contains the search term,
• press enter; the Google Search is begun, the entry briefly contains a Google URL, then Google issues a redirect to https://sugarlabs.org/search/?q=, and the Sugar Labs search page is shown,

So the behaviour is not defined by Browse, but by https://sugarlabs.org/, therefore it is appropriate for this issue in Browse to remain closed.

[Aniket21mathur]

The Issue can be closed. Thanks!

[quozl]

Thanks. I've had second thoughts. Could others please review what I've found;

• Browse URL entry box forces a search of the Sugar Labs web site only if Sugar Labs web site is shown,
• if the index.html of the web site is downloaded, and then served using SimpleHTTPServer python module, the same occurs,
• if the file is changed as follows; the behaviour ceases;

--- /tmp/www/index.html.orig    2019-04-01 16:23:36.256210011 +1100
+++ /tmp/www/index.html 2019-04-01 16:24:09.271768336 +1100
@@ -112,12 +112,6 @@
                var re = document.getElementById("SearchBar").value;
                document.getElementById("searchLink").href = "/search/?q=" + re;
        };
-       document.addEventListener('keyup', function(ev) {
-               if( ev.keyCode == 13 ) {
-                       var re = document.getElementById("SearchBar").value;
-                       document.getElementById("searchLink").href = "/search/?q=" + re;
-                       document.getElementById("searchLink").click();}
-       });
        function expander(){
         if(window.innerWidth > 767){
             document.getElementById("searchForm").style.width="53%";

This means that pressing enter in the URL entry box is executing JavaScript provided by the web page.

How is it that the WebKit2.WebView object is receiving key release events that should have been private to the Browse URL entry box?

[nswarup14]

@quozl
Where is the file that you have shown found?. For www.sugarlabs.org source code, I found a file in /includes/nav.html, or am I talking about the wrong file?

Thanks

[quozl]

There's multiple files involved. I used wget to fetch index.html from the web server. The web server does not transmit the unchanged source.

index.html is the template source file from which the index.html file is built. Line 5 includes nav.html.

So it seems likely you have found the right file.

[quozl]

But the file should not be changed. The fault is with Browse; it should not be forwarding key release events from the URL entry box to the WebView object. Other browsers don't do this.

[rhl-bthr]

The fault is with Browse;

+1; Websites should not be able to take over the browser's expected behavior without asking for permissions

[nswarup14]

@quozl @pro-panda @chimosky
Is there any way to detect the key release events that are being forwarded?

I did a lot of testing on the issue, but I'm unable to pinpoint the source of the issue exactly.

press enter; the Google Search is begun, the entry briefly contains a Google URL, then Google issues a redirect to https://sugarlabs.org/search/?q=, and the Sugar Labs search page is shown,

The link is not being redirected. I was able to verify this by printing out the status of the load operation in the __load_changed_cb of browser.py. WebKit2.LoadEvent.REDIRECTED is never passed.
Rather the google search ends abruptly and a new load operation is begun with the new active URL of https://sugarlabs.org/search/?q=hello

I would really like some guidance on how to proceed.

Thanks!

[quozl]

Thanks for asking.

Yes, that's the result of the JavaScript code on the web site being executed in response to the enter key release event.

However, the problem is that the enter key release event should not have been handed over to the WebKit2.WebView widget.

You could experiment with source code. WebView parent classes include Gtk.Container and Gtk.Widget, so you could capture the key-press-event signal. You could examine source code. WebView class is in the WebKit sources. The GTK widgets are in the GTK sources.

However, it may be simpler to think about the problem entirely differently. Does it happen on other WebKit and GTK browsers? Yes, it does.

sudo apt install epiphany-browser
epiphany-browser https://sugarlabs.org/

So instead of fixing it in Browse, we could log a bug to say that Epiphany (because of WebKit) can be prevented from doing a conventional search by redirecting the user to a crafted web page that contains a JavaScript key handler. This may be more serious than it looks! 😁

I suggest you search Epiphany or WebKit GTK bugs.

Looking back, it was a mistake to assume that the problem is the fault of code in Browse, just because the issue was logged against Browse.

p.s. this is still activity maintenance; we often have to fix or work around problems in other code than our own.