941172 - [User Story] Browser Chrome: Stop

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System::Browser Chrome, defect)

Description

[Peter Dolanjski [:pdol]]

User Story:
As a user I want to stop a page from loading in the event that I no longer want the page to load fully.

Acceptance Criteria:
Functionality should match existing Browser functionality unless described otherwise in UX spec.

Comment 1

[Ben Francis [:benfrancis]]

Estimating as 2 points.

Comment 2

[Ben Francis [:benfrancis]]

Looks like Vivien is working on this in bug 1039519, not much point in it being assigned to me.

https://bugzilla.mozilla.org/show_bug.cgi?id=1039519#c22

Comment 3

[Kevin Grandon :kgrandon]

Francis/Peter - Could you guys do an acceptance run of the current implementation of the stop button in master, and put any comments in this bug? Thanks!

Comment 4

[Francis Djabri [:djabber]]

Attachment: empty view.png

Functionally, the stop button seems to be working as expected. However, there's one case that caused me to get stuck, following these steps:

1) Expand rocket bar
2) Enter in a URL 
3) Hit enter
4) Press stop before any content has loaded. 

This lead to an empty view being loaded, without any content in the browser window or any content in the rocket bar. Tapping on the rocket bar had no effect. 

If the stop button is pressed before any content has been loaded, we should return the user to the search app. 

Also, not sure if it's just my phone, but I'm finding the stop/reload button really hard to target. Only one out of every two or three taps seems to register. What's the tap target size?

Eric, please could you check the stop button to make sure it complies to the visual spec.

Comment 5

[Eric Pang [:epang] UX]

(In reply to Francis Djabri [:djabber] from comment #4)
> Created attachment 8469672 [details]
> empty view.png
> 
> Functionally, the stop button seems to be working as expected. However,
> there's one case that caused me to get stuck, following these steps:
> 
> 1) Expand rocket bar
> 2) Enter in a URL 
> 3) Hit enter
> 4) Press stop before any content has loaded. 
> 
> This lead to an empty view being loaded, without any content in the browser
> window or any content in the rocket bar. Tapping on the rocket bar had no
> effect. 
> 
> If the stop button is pressed before any content has been loaded, we should
> return the user to the search app. 
> 
> Also, not sure if it's just my phone, but I'm finding the stop/reload button
> really hard to target. Only one out of every two or three taps seems to
> register. What's the tap target size?
> 
> Eric, please could you check the stop button to make sure it complies to the
> visual spec.

Same as but 941173 (reload)
This doesn't look like it's been implemented to the visual spec. 

The latest visual spec can be found here:
https://mozilla.box.com/s/oedme1y7u6m3s6lxvk0a

The icons should be much larger - the spec also includes the hit targets.

Image assets can be found here:
https://mozilla.box.com/s/xleyd4fnpl5e2gvo2bxr

Thanks!

Comment 6

[Peter Dolanjski [:pdol]]

We'll leave it open until it matches the UX spec.

Comment 7

[Ben Francis [:benfrancis]]

I added the missing hit states to all the browser chrome buttons in bug 1053936.

Once that lands you will see that the stop button is actually detecting your touches but that it doesn't always have an effect. It seems like there's something going on further down the stack, possibly in the Browser API where calling stop is having no effect in some cases.

The bug where you can get the Rocketbar into a blank un-responsive state sounds like a real bug, but I'm not convinced that pressing stop before a page finishes loading should take you back to the browser start page. I think that would be inconsistent with all the other Firefox browsers which probably just leave you on an empty or partially loaded page.

Comment 8

[Ben Francis [:benfrancis]]

(I increased the size of the stop button as per the spec in bug 941173)

Comment 9

[Ben Francis [:benfrancis]]

I'm going to go ahead and mark this RESOLVED FIXED because I think the Gaia part is now implemented fully to spec.

The issue with the unresponsive button seems like it might be a platform issue which Kan-Ru is investigating in bug 1053946.

The issue with the blank un-responsive Rocketbar I think might be a separate issue which can also be reproduced in other ways, I have filed bug 1054238 to track that as a follow-up.

Please re-open if there are any further issues with the implementation of this feature in Gaia.