Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#3512 closed defect (fixed)

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

Reported by: HoboPrimate Owned by: erikos
Priority: Unspecified by Maintainer Milestone:
Component: Browse Version: 0.95.x
Severity: Unspecified Keywords: 12.1.0, patch, olpc-test-passed
Cc: manuq, humitos Distribution/OS: Fedora
Bug Status: Unconfirmed

Description (last modified by manuq)

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:

Change History (32)

comment:1 Changed 8 years ago by callkalpa

With the patch the new tabs will say "Ready"

comment:2 follow-up: Changed 8 years ago by 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...

comment:3 in reply to: ↑ 2 ; follow-up: Changed 8 years ago by 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.

comment:4 in reply to: ↑ 3 ; follow-up: Changed 8 years ago by 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).

comment:5 in reply to: ↑ 4 Changed 8 years ago by 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

comment:6 Changed 8 years ago by manuq

  • Cc manuq added

comment:7 Changed 8 years ago by humitos

  • Cc humitos added

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?

Changed 8 years ago by humitos

manuq's test

comment:8 Changed 8 years ago by manuq

  • Description modified (diff)
  • Summary changed from New tab shows small progress bar in the adress, and says "Loading..." at the bottom to 'about:blank' is not handled properly, is not finishing the loading

comment:9 Changed 8 years ago by manuq

  • Milestone changed from Unspecified by Release Team to 0.96

comment:10 Changed 8 years ago by manuq

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

comment:11 Changed 8 years ago by 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.

comment:12 Changed 8 years ago by humitos

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

Great work!

comment:13 follow-up: Changed 8 years ago by manuq

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

comment:14 in reply to: ↑ 13 ; follow-up: Changed 8 years ago by 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.

Changed 8 years ago by humitos

comment:15 in reply to: ↑ 14 Changed 8 years ago by 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.

comment:16 Changed 8 years ago by manuq

  • Keywords patch added

comment:18 Changed 8 years ago by manuq

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

comment:19 Changed 8 years ago by manuq

  • Description modified (diff)

comment:20 Changed 8 years ago by manuq

  • Keywords 12.1.0 olpc-test-pending added
  • Resolution set to fixed
  • Status changed from new to closed

Pushed as 8057d68dda9808485cd8e36482d01eff33e2e8c9 .

comment:21 follow-up: Changed 8 years ago by greenfeld

  • Keywords olpc-test-pending removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

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

comment:22 in reply to: ↑ 21 Changed 8 years ago by 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

comment:23 Changed 8 years ago by humitos

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

comment:24 Changed 8 years ago by manuq

  • Keywords olpc-test-pending added
  • Resolution set to fixed
  • Status changed from reopened to closed

Thanks for testing.

comment:25 Changed 8 years ago by greenfeld

  • Keywords olpc-test-passed added; olpc-test-pending removed

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

comment:26 Changed 7 years ago by dnarvaez

  • Milestone 0.96 deleted

Milestone 0.96 deleted

Note: See TracTickets for help on using tickets.