After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 775710 - Progress bar difficult to see (high DPI screen?)
Progress bar difficult to see (high DPI screen?)
Status: RESOLVED OBSOLETE
Product: epiphany
Classification: Core
Component: Interface
3.22.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-12-06 13:54 UTC by Harshad
Modified: 2018-08-03 20:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
embed: Remove the progress bar (4.46 KB, patch)
2016-12-06 15:27 UTC, Michael Catanzaro
committed Details | Review

Description Harshad 2016-12-06 13:54:51 UTC
Hello all, 

On my laptop with a 13.3" 3200x1600 high DPI screen, the Epiphany progress indicator is difficult to see. This is compounded by the fact that the highlighted tab is indicated with a blue bar that is nearly identical and adjacent. 

I think the progress bar needs to be moved or resized. I am not sure if this is because of the DPI on my screen.

Possible options include:

1. Increasing the thickness
2. Progressively shading the the URL box
3. Progressively shading the tab
4. Ditching the progress bar all together and switching to a simple per tab spinner ala Chromium. Perhaps with a % indicator

Personally, I like #4 the most :)

I am on 3.23.3 on Arch Linux.
Comment 1 Michael Catanzaro 2016-12-06 15:13:00 UTC
I'm thinking we should go with #4, unless anyone wants to improve the style of the progress bar to mitigate this issue. This is far from the first time I've seen complaints about it, so I think the progress bar in its current form has got to go. My only hesitation with #4 is there's not currently any way to see if the page is still loading when there's only one tab open.

P.S. Another disadvantage of the progress bar is it indicates that slow nonessential subresources are still loading after the rest of the page is present, which makes users think we are slower than other browsers.
Comment 2 Michael Catanzaro 2016-12-06 15:27:23 UTC
Created attachment 341486 [details] [review]
embed: Remove the progress bar

It does nothing except make us look slower than other browsers, and has
serious style issues.
Comment 3 Harshad 2016-12-06 16:17:31 UTC
Excellent! Thank you. 

The stop/refresh button already indicates when the page is loading / done loading. This might be sufficient in the 1 tab case. If not, perhaps the stop symbol could be changed to a 'spinner'.
Comment 4 Michael Catanzaro 2016-12-06 16:41:31 UTC
(In reply to Harshad from comment #3)
> Excellent! Thank you. 
> 
> The stop/refresh button already indicates when the page is loading / done
> loading.

Oh yeah, good point. So that was my only hesitation to removing the progress bar. I'll still leave this open for a day or two to give others a chance to object before landing.
Comment 5 Lapo Calamandrei 2016-12-06 20:38:10 UTC
I'm not a great fan of that progressbar as well, I don't like having different baheviours if there are tabs or not though.
Comment 6 Michael Catanzaro 2016-12-07 14:37:13 UTC
Attachment 341486 [details] pushed as 14249f5 - embed: Remove the progress bar
Comment 7 Michael Catanzaro 2017-01-14 03:16:42 UTC
(In reply to Harshad from comment #3)
> The stop/refresh button already indicates when the page is loading / done
> loading. This might be sufficient in the 1 tab case. If not, perhaps the
> stop symbol could be changed to a 'spinner'.

Yeah we're going to need a spinner somewhere, reverting this. :(
Comment 8 GNOME Infrastructure Team 2018-08-03 20:57:22 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/epiphany/issues/351.