Browse has no "busy" indication

[martin.langhoff]

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

[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.

[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.

[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

[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.

[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.

[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.

[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...

[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!

[sascha_silbe]

Bulk change distribution=SoaS -> component=SoaS

[sdz]

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

[erikos]

New F14 ticket  https://bugzilla.redhat.com/show_bug.cgi?id=640581

[RafaelOrtiz]

Moving to 0.92

[RafaelOrtiz]

see

 http://dev.laptop.org/ticket/10684#comment:7

For proposed fix.

[manuq]

We should rethink this for the next milestone, 0.98.

[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:

•  http://git.sugarlabs.org/paint/mainline/blobs/master/Area.py#line674

[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:

*  http://git.sugarlabs.org/paint/mainline/blobs/master/Area.py#line674

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

[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?

[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)

[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)

[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.

[martin.langhoff]

one tab can be waiting, but not all

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

[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"

[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.

[godiard]

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

[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?

[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?

[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.

[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?

[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.

[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.

[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.

[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)

[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 ;)

[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.

[humitos]

Please, reconsider applying it again as it is.

[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.

[manuq]

Thanks, pushed as a07d27a0 with slight modifications:

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