'about:blank' is not handled properly, is not finishing the loading

[HoboPrimate]

As consequence, new tab shows small progress bar in the adress, and says "Loading..." at the bottom.

Test Case:

• open a new tab, using the '+' button or Ctrl + t shortcut
• the URL entry should not display a progress bar, the label in the tab should say "Untitled"

If the bug is present, you'll see a small progress bar in the address bar of the new tab. And it will say "Loading..." in the label.

Other test:

Write 'about:blank' in the URL entry and hit enter, the behaviour expected is the same as above.

Test Case for PDF:

• write in the url entry: " http://dev.laptop.org/~manuq/SimpleGraph.pdf"
• a new tab opens with the PDF
• go to the previous tab, the content should be the same as before

[callkalpa]

With the patch the new tabs will say "Ready"

[garycmartin]

I thought these "Loading..." and URL messages in the bottom left of the screen were debug text messages while testing web kit, not an intended Browse feature to ship. At the very least they are rather distracting, not Sugar like, do not work for touch enabled devices (i.e. no ability to hover a cursor over a link), and should at best only appear if you delay hover over a link.

The "Loading..." message is superfluous to the design, that is what the Browse loading progress bar is there to indicate...

[callkalpa]

Replying to garycmartin:

I thought these "Loading..." and URL messages in the bottom left of the screen were debug text messages while testing web kit, not an intended Browse feature to ship. At the very least they are rather distracting, not Sugar like, do not work for touch enabled devices (i.e. no ability to hover a cursor over a link), and should at best only appear if you delay hover over a link.

The "Loading..." message is superfluous to the design, that is what the Browse loading progress bar is there to indicate...

In the case where it takes a lot of time to load and the progress bar takes a considerable time to show a significant change (specially at the very beginning), still the user will know that the page is loading.

[garycmartin]

Replying to callkalpa:

Replying to garycmartin:

I thought these "Loading..." and URL messages in the bottom left of the screen were debug text messages while testing web kit, not an intended Browse feature to ship. At the very least they are rather distracting, not Sugar like, do not work for touch enabled devices (i.e. no ability to hover a cursor over a link), and should at best only appear if you delay hover over a link.

The "Loading..." message is superfluous to the design, that is what the Browse loading progress bar is there to indicate...

In the case where it takes a lot of time to load and the progress bar takes a considerable time to show a significant change (specially at the very beginning), still the user will know that the page is loading.

A graphical spinner in the Tab can be used to avoid localisation of the word "Loading...", or the word Loading... could be the Tab name while loading, or a graphical spinner could be shown in the middle of the loading canvas space (ideally composited over whatever page is there, but it could be a solid rectangle with a spinner on it).

[callkalpa]

Replying to garycmartin:

Replying to callkalpa:

Replying to garycmartin:

I thought these "Loading..." and URL messages in the bottom left of the screen were debug text messages while testing web kit, not an intended Browse feature to ship. At the very least they are rather distracting, not Sugar like, do not work for touch enabled devices (i.e. no ability to hover a cursor over a link), and should at best only appear if you delay hover over a link.

The "Loading..." message is superfluous to the design, that is what the Browse loading progress bar is there to indicate...

In the case where it takes a lot of time to load and the progress bar takes a considerable time to show a significant change (specially at the very beginning), still the user will know that the page is loading.

A graphical spinner in the Tab can be used to avoid localisation of the word "Loading...", or the word Loading... could be the Tab name while loading, or a graphical spinner could be shown in the middle of the loading canvas space (ideally composited over whatever page is there, but it could be a solid rectangle with a spinner on it).

A graphical spinner like in firefox will look nice

[humitos]

I was researching about this problem.

I found that the progress bar, webkit and our browser work good. I mean, there is no problem neither with the "progress" value of the webkit nor with opening a new tab as we (manuq and I) thought; instead the problem is with the "about:blank" page.

Try this:

1. Open Browse, you will see the sugar labs page by default
2. Go to the URL address bar and type: "about:blank"
3. You will see the "Loading.." at the bottom and you will see the progress bar in the 10%, right?

Well, the problem here is that webkit stops in this status: "<enum WEBKIT_LOAD_PROVISIONAL of type WebKitLoadStatus>" with progress in 0.1 (10%) and it never gets the "<enum WEBKIT_LOAD_FINISHED of type WebKitLoadStatus>" status with progress in 1.0 (100%)

So, the question is: why when you open "about:blank" webkit never gets the FINISHED status?

[humitos]

manuq's test

[manuq]

Commenting the connection to mime-type-policy-decision-requested signal in Browse class makes the about:blank page finish.

[manuq]

We were not returning the right value, the callback should return True if the signal is handled, False otherwise. Patch sent to the list.

[humitos]

This patch works for me in sugar-jhbuild debian testing and XO 1.75 os8 (both with git version of browse)

Great work!

[manuq]

Is good to test if downloads and PDF reading keep working. They do for me.

[humitos]

Replying to manuq:

Is good to test if downloads and PDF reading keep working. They do for me.

OK.

I tested this in XO 1.75 and Debian jhbuild. I can see the PDF in the XO in a new tab but in the original one I see the content of the pdf file (screenshot attached)

In Debian I don't have python-evince so I can not see the PDF file.

[manuq]

Replying to humitos:

Replying to manuq:

Is good to test if downloads and PDF reading keep working. They do for me.

OK.

I tested this in XO 1.75 and Debian jhbuild. I can see the PDF in the XO in a new tab but in the original one I see the content of the pdf file (screenshot attached)

Thanks for testing. Seems that we need to return False for PDF, I don't exactly understand why, as we are handling the request, but it works. New patch v2 sent with this change.

[humitos]

 http://webkitgtk.org/reference/webkitgtk/unstable/webkitgtk-webkitwebview.html#WebKitWebView-mime-type-policy-decision-requested

[manuq]

v3

[manuq]

So, the v3 patch is the latest attached, 0001-Fix-for-the-MIME-type-handling-of-a-request-SL-3512.patch.

[manuq]

Pushed as 8057d68dda9808485cd8e36482d01eff33e2e8c9 .

[greenfeld]

I still see "Loading..." when opening the PDF file suggested or about:blank in 12.1.0 os10/Browse-137.

[humitos]

Replying to greenfeld:

I still see "Loading..." when opening the PDF file suggested or about:blank in 12.1.0 os10/Browse-137.

This case is related with #3597

[humitos]

I've just tested this with the latest git version of Browse and it's working properly for me.

[manuq]

Thanks for testing.

[greenfeld]

Browse-140/12.1.0 os16 shows "Untitled" for about:blank or the appropriate language translation thereof.