1082103 - [Youtube] If you disable network connection and refresh page, error message 'Cancel' button is unresponsive

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Robert Mead [:RobertM]]

Attachment: Flame2.1logcat.txt

Description:
If you go to youtube, disconnect your network connection, tap on a video, then refresh the page to make the Network Connection Error page appear, the 'Cancel' button on the bottom of the page will be unresponsive.
   
Prereq:
Make sure device is connected to a network with internet.

Repro Steps:
1) Update a Flame device to BuildID: 20141013001201
2) Launch Browser and navigate to Youtube.
3) Once page loads, pull down utility tray and disable the network.
4) Tap on one of the video links.
5) While the next page is trying to load, hit the refresh button.
6) The error page should display. Go to bottom of page and tap 'Cancel' button.
  
Actual:
The button is unresponsive, so nothing happens.
  
Expected: 
The Browser closes and returns you to the homescreen.
  

Flame 2.1(319mb)(Full Flash)

Environmental Variables:
Device: Flame 2.1
BuildID: 20141013001201
Gaia: d18e130216cd3960cd327179364d9f71e42debda
Gecko: 610ee0e6a776
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

  
Repro frequency: 100%
See attached: logcat, video - http://youtu.be/JDgK8T2Kuis

Comment 1

[Robert Mead [:RobertM]]

This issue also occurs on Flame 2.2 (319mb) and Flame 2.0 (319mb)

If you go to youtube, disable your internet, tap on a link, then refresh the next page to get the error page, the 'Cancel' button at the bottom of the page becomes unresponsive.


Flame 2.2 

Device: Flame 2.2 Master KK (319mb) (Full Flash)
BuildID: 20141013040202
Gaia: 3b81896f04a02697e615fa5390086bd5ecfed84f
Gecko: f547cf19d104
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0


Flame 2.0

Device: Flame 2.0 KK (319mb) (Full Flash)
BuildID: 20141013000204
Gaia: 6effca669c5baaf6cd7a63c91b71a02c6bd953b3
Gecko: 54ec9cb26b59
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 32.0 (2.0)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 2

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

[Blocking Requested - why for this release]:

Cancel button is completely unresponsive. If the user walks out of wifi range and runs into this error screen, the user will not be able to select the cancel button. Nominating this to block

Comment 3

[Kevin Grandon :kgrandon]

I'm not even sure what Cancel should do in this case. Maybe we should just get rid of it? Francis - any thoughts?

Comment 4

[Rachelle Yang [:ryang][[e-mail]]]

Hi Ben, could you please kindly check on this ?

Triage to denominate it for now .

Comment 5

[Manuel Casas Barrado [:mancas]]

The problem here is that the cancel button navigates through the |window.history| calling to the function |back| . If we just have visited a single page, then the browser will be closed, but in the other hand, if our history has more than one page, then we will start to navigate through the pages. So we can close the browser after check the browser history or as I suggest, we can replace the cancel button with a "retry" button which makes more sense for me because if we don't have internet connection and we start navigate back... when the connection is available again, the user could be at the first page he/she visited and I believe this is a bad experience

Comment 6

[Ben Francis [:benfrancis]]

Thanks for taking this Manuel, these error pages are not part of the browser app but are defined in chrome I think.

Would be good to get Francis' input on expected behaviour as Kevin suggested.

Comment 7

[Francis Djabri [:djabber]]

The Cancel button simply closes the error page and returns the user to the page from which the error page was called. Here is a link to the original spec: https://mozilla.box.com/s/q3mh4svgs5lg63cf68us. I think the Cancel button is needed - some users may just not be comfortable being stuck on an error page, especially as the error page appears like a dialog. 

There is no need for a "Try again" button because if a connection is re-established, the error page automatically dismisses and the page loads as originally intended.

Comment 8

[Manuel Casas Barrado [:mancas]]

In that case, the button is working as expected, so there is no reason to modify the code here. We will close and mark this bug as WORKSFORME. Do you agree?

Comment 9

[Francis Djabri [:djabber]]

No. For me, the expected behavior would be to return the user to the YouTube main page in this case. If the user attempts a page reload when offline, the Cancel button should take the user back to the previous page - in this case, the YouTube main page. If there is no previous history in the browser window, then close the window.

Comment 10

[Manuel Casas Barrado [:mancas]]

(In reply to Francis Djabri [:djabber] from comment #9)
> No. For me, the expected behavior would be to return the user to the YouTube
> main page in this case. If the user attempts a page reload when offline, the
> Cancel button should take the user back to the previous page - in this case,
> the YouTube main page. If there is no previous history in the browser
> window, then close the window.

This is the current behavior. The problem is when we go back in the history and the connection is not available, we see the error page again. There is just one case in what the browser is closed: The error page is shown at the first time we enter in the browser, then tapping in 'cancel' button the browser is closed because we have no previous history:

|hasHistory() ? goBack() : closeWindow();|

Comment 11

[Kevin Grandon :kgrandon]

This is because youtube sets a onunload which breaks bfcache. This is an evangelism/website issue and there's nothing we can do in gaia about this. If you try this with other websites, the browser should behave as expected. 

I'm going to mark this as a wontfix because this only happens with sites that break bfcache (by using window.onunload).