Opened 5 years ago

Closed 2 years ago

Last modified 13 months ago

#851 closed defect (fixed)

Browse has no "busy" indication

Reported by: martin.langhoff Owned by: humitos
Priority: Urgent Milestone:
Component: Browse Version: 0.84.x
Severity: Critical Keywords: patch, screenshot
Cc: sridhar, godiard, humitos, garycmartin, manuq Distribution/OS: Unspecified
Bug Status: Assigned

Description

Browse right now has a progress bar it displays once download is progressing. Before the progress bar appears there can be a significant lag, during which the user wonders "did I click on that link/button or not?".

On 0.82 the cursor changed when busy to have a "rotating arrow" animation. This is gone on 0.84

Attachments (3)

0001-Busy-indication-SL-851.patch (1.3 KB) - added by humitos 2 years ago.
watch_cursor.png (91.7 KB) - added by humitos 2 years ago.
0001-Busy-indication-SL-851.2.patch (4.5 KB) - added by humitos 2 years ago.

Download all attachments as: .zip

Change History (48)

comment:1 follow-up: Changed 5 years ago by erikos

  • Bug Status changed from Unconfirmed to New
  • Milestone changed from soas_fossvt to 0.86
  • Priority changed from Unspecified by Maintainer to High
  • Severity changed from Unspecified to Critical
  • Version changed from Unspecified to 0.84.x

Thanks for the report. This is true for all 0.84 - not only Soas. I mark this critical as it is a regression. /me wonders at which level the bug is though... Hints from the cursor fraction welcome.

comment:2 in reply to: ↑ 1 ; follow-up: Changed 5 years ago by tomeu

Replying to erikos:

Thanks for the report. This is true for all 0.84 - not only Soas. I mark this critical as it is a regression. /me wonders at which level the bug is though... Hints from the cursor fraction welcome.

I would suspect a change in mozilla, we should be able to set the cursor at will on the hulahop widget as in any other gtk widget.

comment:3 Changed 5 years ago by erikos

  • Priority changed from High to Urgent

comment:4 in reply to: ↑ 2 Changed 5 years ago by tomeu

Replying to tomeu:

Replying to erikos:

Thanks for the report. This is true for all 0.84 - not only Soas. I mark this critical as it is a regression. /me wonders at which level the bug is though... Hints from the cursor fraction welcome.

I would suspect a change in mozilla, we should be able to set the cursor at will on the hulahop widget as in any other gtk widget.

Upstream ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=482985

Offending patch: https://bugzilla.mozilla.org/attachment.cgi?id=365464&action=diff

comment:5 Changed 5 years ago by erikos

Would be nice to get the cursor back. The issue is not as bad anymore, though. With moving to the new toolbar design the address entry is always visible giving at least some information of loading time.

comment:6 Changed 5 years ago by erikos

Very good progress upstream. https://bugzilla.mozilla.org/show_bug.cgi?id=482985

Markus Stange added a patch to add a ui.use_activity_cursor preference for the spinning cursor.

comment:7 Changed 5 years ago by erikos

  • Bug Status changed from New to Assigned

comment:8 Changed 5 years ago by tomeu

Asked Fedora to apply this patch:

https://bugzilla.redhat.com/show_bug.cgi?id=524377

Now that this has been applied to upstream's HEAD, we can ask distros to carry this patch.

comment:9 follow-up: Changed 5 years ago by martin.langhoff

Tomeu, Erikos, once this is in xulrunner, do we need to make any changes in Browse.xo or will it automagically work again?

BTW, asking for help on fedora-olpc-list...

comment:10 in reply to: ↑ 9 Changed 5 years ago by tomeu

Replying to martin.langhoff:

Tomeu, Erikos, once this is in xulrunner, do we need to make any changes in Browse.xo or will it automagically work again?

We would need to set the ui.use_activity_cursor pref to True, I guess. Like this:

http://git.sugarlabs.org/projects/browse/repos/mainline/blobs/master/webactivity.py#line149

BTW, asking for help on fedora-olpc-list...

Thanks!

comment:11 Changed 4 years ago by sascha_silbe

  • Component changed from Browse to SoaS
  • Distribution/OS changed from SoaS to Unspecified
  • Owner changed from erikos to mchua sdz

Bulk change distribution=SoaS -> component=SoaS

comment:12 Changed 4 years ago by sdz

  • Component changed from SoaS to Browse
  • Owner changed from mchua sdz to erikos

Assigning back to browse, just to make sure we're alright. What's the status here?

comment:13 Changed 4 years ago by erikos

  • Milestone changed from 0.86 to 0.90

comment:14 Changed 4 years ago by sridhar

  • Cc sridhar added

comment:15 Changed 3 years ago by RafaelOrtiz

  • Milestone changed from 0.90 to 0.92

Moving to 0.92

comment:16 Changed 3 years ago by RafaelOrtiz

  • Milestone changed from 0.92 to 0.94

comment:17 Changed 3 years ago by RafaelOrtiz

comment:18 Changed 2 years ago by manuq

  • Milestone changed from 0.94 to 0.98

comment:19 Changed 2 years ago by manuq

We should rethink this for the next milestone, 0.98.

comment:20 follow-up: Changed 2 years ago by humitos

  • Cc godiard humitos added

I tested thi on build 14 and it still happens.

We should use something like this (from Paint's code) to set the WATCH cursor:

comment:21 in reply to: ↑ 20 ; follow-up: Changed 2 years ago by erikos

Replying to humitos:

I tested thi on build 14 and it still happens.

We should use something like this (from Paint's code) to set the WATCH cursor:

The problem is that changing the cursor would only solve the non-touch case.

Changed 2 years ago by humitos

comment:22 Changed 2 years ago by humitos

  • Keywords patch added

comment:23 in reply to: ↑ 21 Changed 2 years ago by humitos

Replying to erikos:

The problem is that changing the cursor would only solve the non-touch case.

I've just seen this comment. Maybe we can add an animation into the tab, like Firefox does. What do you think?

comment:24 follow-up: Changed 2 years ago by martin.langhoff

No, I don't think this is the right track.

  • In 2013, nobody accepts a webbrowser that during loading would switch to a pure "busy" cursor... it's like back to Netscape 2.0 on Windows 3.11 . Please observe that in 11.3.x Browse has a nice pointer + busy spinner (left_ptr_watch it is called in the gnome theme) indicating you can still click on things.
  • We will be hiding the cursor quite often (on touch units at least). So Browse needs a spinner somewhere in the toolbar. (I see erikos has made this same point)

comment:25 Changed 2 years ago by godiard

+1 to left_ptr_watch

About the second comment, toolbar in Browse is already packed. Do we really need another indication than the "Loading ..." in the url entry and the progress bar?
If we _really_ need it, may be we can add a icon to the tab (one tab can be waiting, but not all)

comment:26 Changed 2 years ago by martin.langhoff

If loading and the progress bar appear _immediately_, it may be ok. But usually, they don't -- IIRC, they appear after the DNS lookup, though that may be an xulrunner artifact. Look at your transformer -- each tab has a spinner. Look at any iOS device. These are important bits of UI feedback.

On the same track of "did I click that link?" UI in Browse (actually, "did this damn computer realize I clicked that link"? ;-) ) -- it would be great to flash the "box" of the A element. On a quick test, my Android phone does it.

comment:27 follow-up: Changed 2 years ago by martin.langhoff

one tab can be waiting, but not all

In all the webbrowsers we use today many tabs can be waiting.

comment:28 in reply to: ↑ 27 Changed 2 years ago by godiard

Replying to martin.langhoff:

one tab can be waiting, but not all

In all the webbrowsers we use today many tabs can be waiting.

Yeah. I should rephrase "Wait state is for a tab, not for all the tabs, then the toolbar is not a good place for a spinner"

comment:29 follow-up: Changed 2 years ago by martin.langhoff

Ok - sorry, I completely misunderstood. Yes, it possibly belongs to a tab... if there is one. But I think right now we always display a tab, correct? In that case, all clear.

comment:30 in reply to: ↑ 29 Changed 2 years ago by godiard

  • Cc garycmartin manuq added

Replying to martin.langhoff:

Ok - sorry, I completely misunderstood. Yes, it possibly belongs to a tab... if there is one. But I think right now we always display a tab, correct? In that case, all clear.

Yes, we always have at least one open tab.

CC to Gary and Manuq to have DESIGN involved

comment:31 in reply to: ↑ 24 Changed 2 years ago by humitos

Replying to martin.langhoff:

  • In 2013, nobody accepts a webbrowser that during loading would switch to a pure "busy" cursor... it's like back to Netscape 2.0 on Windows 3.11 . Please observe that in 11.3.x Browse has a nice pointer + busy spinner (left_ptr_watch it is called in the gnome theme) indicating you can still click on things.

Yes, sorry. I've already known about this cursor, I don't know why I didn't used it. Sorry.

Should I fix my patch? Are we going to use this approach for the non-touch case?

comment:32 Changed 2 years ago by humitos

  • Owner changed from erikos to humitos
  • Status changed from new to accepted

comment:33 follow-up: Changed 2 years ago by manuq

I think the proper solution is show a spinner in the tab, placed at the left of the page title. Even better, show the site icon (favicon) in that place when the tab is not loading. But if the spinner is going to be attacked first, then that space should be a placeholder to prevent resizing when the spinner appears.

In fact is easy to get the favicon with webkit: there are get_icon_pixbuf and get_icon_uri methods.

What do you think Gary?

comment:34 Changed 2 years ago by manuq

GtkSpinner documentation: http://developer.gnome.org/gtk/stable/GtkSpinner.html

GtkSpinner usage in Epiphany: http://git.gnome.org/browse/epiphany/tree/src/ephy-notebook.c#n567

We may have to theme this with the .spinner class in the sugar artwork.

comment:35 in reply to: ↑ 33 ; follow-up: Changed 2 years ago by garycmartin

Replying to manuq:

I think the proper solution is show a spinner in the tab, placed at the left of the page title.

Even better, show the site icon (favicon) in that place when the tab is not loading. But if the spinner is going to be attacked first, then that space should be a placeholder to prevent resizing when the spinner appears.

In fact is easy to get the favicon with webkit: there are get_icon_pixbuf and get_icon_uri methods.


What do you think Gary?

Looking at the current tab sizes, I'm worried abut the extra space this will take up, and also not convinced we should add favicons as many will not be designed for the dark tab backgrounds, and we will also need an alternative default icon place holder for the domains that don't have a favicon set.

The solution used in Safari (iOS and OSX) that would work for us is to start the completion bar at ~5-10% immediately a link is clicked or URL entered. The odd thing is, this seems to be exactly how Browse is behaving today in 13.0.1 build 2. I've tried to reproduce the original case where the completion bar lags and have not yet managed it (using slow sites, bad domain names, dropping the wan connection), a part of the progress bar is always appearing instantly. Can we have a test case please, this may be a resurrected stale ticket gone rogue (this is 3 years old now), or perhaps the current completion bar feedback is not enough?

comment:36 in reply to: ↑ 35 Changed 2 years ago by manuq

Replying to garycmartin:

Replying to manuq:
The solution used in Safari (iOS and OSX) that would work for us is to start the completion bar at ~5-10% immediately a link is clicked or URL entered. The odd thing is, this seems to be exactly how Browse is behaving today in 13.0.1 build 2. I've tried to reproduce the original case where the completion bar lags and have not yet managed it (using slow sites, bad domain names, dropping the wan connection), a part of the progress bar is always appearing instantly. Can we have a test case please, this may be a resurrected stale ticket gone rogue (this is 3 years old now), or perhaps the current completion bar feedback is not enough?

I second this. We start instantly the progress bar with a "Loading..." text, of course more feedback never hurts, but I think this should be enough.

comment:37 follow-up: Changed 2 years ago by martin.langhoff

I see that Browse shows progress bar immediately. That's good.

If we can also apply the "left_ptr_watch" patch, and we don't need to carry patches on webkit-gtk (as we had to do against xulrunner, for this same feature), I think it is worthwhile.

The reason it is worthwhile is that the user is looking at the cursor when they click, so the change of cursor with left_ptr_watch is immediate effective feedback in the locus of sight.

OTOH, if this is a painful or problematic patch, I'll agree to defer it or cancel it.

comment:38 in reply to: ↑ 37 ; follow-up: Changed 2 years ago by manuq

Replying to martin.langhoff:

I see that Browse shows progress bar immediately. That's good.

If we can also apply the "left_ptr_watch" patch, and we don't need to carry patches on webkit-gtk (as we had to do against xulrunner, for this same feature), I think it is worthwhile.

The reason it is worthwhile is that the user is looking at the cursor when they click, so the change of cursor with left_ptr_watch is immediate effective feedback in the locus of sight.

Yes! and we use it also wnen the activity is stopping, so let's change the cursor in the patch and push. Webkit is not as problematic as xulrunner for this.

comment:39 in reply to: ↑ 38 ; follow-up: Changed 2 years ago by godiard

Replying to manuq:

Replying to martin.langhoff:

I see that Browse shows progress bar immediately. That's good.

If we can also apply the "left_ptr_watch" patch, and we don't need to carry patches on webkit-gtk (as we had to do against xulrunner, for this same feature), I think it is worthwhile.

The reason it is worthwhile is that the user is looking at the cursor when they click, so the change of cursor with left_ptr_watch is immediate effective feedback in the locus of sight.

Yes! and we use it also wnen the activity is stopping, so let's change the cursor in the patch and push. Webkit is not as problematic as xulrunner for this.

+1 Just remember this is "left_ptr_watch" and not "watch" (used when activity is stoped)

comment:40 in reply to: ↑ 39 ; follow-up: Changed 2 years ago by garycmartin

Replying to godiard:

Replying to manuq:

Replying to martin.langhoff:

I see that Browse shows progress bar immediately. That's good.

If we can also apply the "left_ptr_watch" patch, and we don't need to carry patches on webkit-gtk (as we had to do against xulrunner, for this same feature), I think it is worthwhile.

The reason it is worthwhile is that the user is looking at the cursor when they click, so the change of cursor with left_ptr_watch is immediate effective feedback in the locus of sight.

Yes! and we use it also wnen the activity is stopping, so let's change the cursor in the patch and push. Webkit is not as problematic as xulrunner for this.

+1 Just remember this is "left_ptr_watch" and not "watch" (used when activity is stoped)

+1, in case anyone was loitering for extra comments ;)

comment:41 in reply to: ↑ 40 Changed 2 years ago by humitos

Replying to garycmartin:

+1, in case anyone was loitering for extra comments ;)

I think all of us were confused at this point. There is no cursor called: left_ptr_watch:

In [1]: from gi.repository import Gdk

In [2]: Gdk.CursorType.LEF
Gdk.CursorType.LEFTBUTTON  Gdk.CursorType.LEFT_PTR    Gdk.CursorType.LEFT_SIDE   Gdk.CursorType.LEFT_TEE    

In [2]: Gdk.CursorType.LEFT

But anyway, the patch already sent with WATCH cursor is exactly what we want. The left arrow with a "watch arrow" (like a circle) on it. Take a look at my screenshot attached.

Changed 2 years ago by humitos

comment:42 Changed 2 years ago by humitos

  • Keywords screenshot added

Please, reconsider applying it again as it is.

comment:43 Changed 2 years ago by manuq

Yes, that cursor is the same as the one used while the activity is stopping, commit ab643a10 of the toolkit.

Humitos your patch does not consider switching tabs. Testcase:

  1. start loading a big page in one tab
  2. switch to another tab already loaded or empty
  3. switch back to the previous tab, still loading

Cursor should change to spinner arrow in 1, normal arrow in 2, and back to spinner arrow in 3.

Changed 2 years ago by humitos

comment:44 Changed 2 years ago by manuq

  • Resolution set to fixed
  • Status changed from accepted to closed

Thanks, pushed as a07d27a0 with slight modifications:

  • removed constants for gdk constants and used them directly
  • fixed style of docstring

comment:45 Changed 13 months ago by dnarvaez

  • Milestone 0.98 deleted

Milestone 0.98 deleted

Note: See TracTickets for help on using tickets.