Closed Bug 1087042 Opened 10 years ago Closed 10 years ago

Progress bar displays in the place for the Guardian app

Categories

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

x86
macOS
defect
Not set
normal

Tracking

(blocking-b2g:2.1+, b2g-v2.1 fixed, b2g-v2.2 verified)

VERIFIED FIXED
2.1 S8 (7Nov)
blocking-b2g 2.1+
Tracking Status
b2g-v2.1 --- fixed
b2g-v2.2 --- verified

People

(Reporter: gwagner, Assigned: apastor)

References

()

Details

(Whiteboard: [systemsfe])

Attachments

(3 files)

Attached image 2014-10-22-01-41-32.png
On 2.1: STR: Install "The Guardian" app from marketplace Pull down rocketbar
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.1?
Whiteboard: [systemsfe]
That's not the notification indicator, that's the progress bar displaying at the top of the page when it should be underneath the rocketbar. Alberto, can you take a look here?
Flags: needinfo?(apastor)
Summary: Notification indicator visible without pending notification → Progress bar displays in the place for the Guardian app
Assignee: nobody → apastor
Flags: needinfo?(apastor)
Is there any spec available about this? Thanks!
Flags: needinfo?(epang)
(In reply to Alberto Pastor [:albertopq] from comment #3) > Is there any spec available about this? Thanks! Hey Francis, can we get your help for the ixd on this? I can see the need for a progress bar for some apps. But for others like Huff Post is it needed? From the looks of the screen it looks like the app already has it's own loading bar built in. Is there a way we can check if it's needed?
Flags: needinfo?(epang) → needinfo?(fdjabri)
(In reply to Eric Pang [:epang] from comment #4) > (In reply to Alberto Pastor [:albertopq] from comment #3) > > Is there any spec available about this? Thanks! > > Hey Francis, can we get your help for the ixd on this? > > I can see the need for a progress bar for some apps. But for others like > Huff Post is it needed? From the looks of the screen it looks like the app > already has it's own loading bar built in. Is there a way we can check if > it's needed? Francis, disregard my last comment, for some reason I was testing with Huff Post instead of Guardian! But this brings up a separate question :). When the rocket bar is expanded the progress bar is shown below. But when the app is in full screen currently no progress bar is shown when loading pages. Should the progress bar should at the top of the screen?
Flags: needinfo?(fdjabri)
(In reply to Eric Pang [:epang] from comment #5) > (In reply to Eric Pang [:epang] from comment #4) > > (In reply to Alberto Pastor [:albertopq] from comment #3) > > > Is there any spec available about this? Thanks! > > > > Hey Francis, can we get your help for the ixd on this? > > > > I can see the need for a progress bar for some apps. But for others like > > Huff Post is it needed? From the looks of the screen it looks like the app > > already has it's own loading bar built in. Is there a way we can check if > > it's needed? > > Francis, disregard my last comment, for some reason I was testing with Huff > Post instead of Guardian! > > But this brings up a separate question :). > > When the rocket bar is expanded the progress bar is shown below. But when > the app is in full screen currently no progress bar is shown when loading > pages. Should the progress bar should at the top of the screen? need info on comment 4
Flags: needinfo?(fdjabri)
Apart from the progress bar problem, I cannot see the statusbar when pulling down the rocketbar. Adding qawanted for making sure that's only happening in master.
Keywords: qawanted
QA Contact: ckreinbring
The bug repros on Flame 2.2 and Flame 2.1 engineering builds with shallow flash. Actual result: When swiping down from the top of the screen while having The Guardian app open, the user sees the loading/progress bar above the rocketbar instead of below. Further, the status bar does not appear. Flame 2.2 BuildID: 20141021230530 Gaia: 4d7f051cede6544f4c83580253c743c22b0cb279 Gecko: ae4d9b4ff2ee Platform Version: 36.0a1 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Flame 2.1 BuildID: 20141021142533 Gaia: 3d9cc667f4e929861a9a77c41096bbf5a9c1bde0 Gecko: 928b18f7d8ff Platform Version: 34.0 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 -------------------------------------------------------------------------------------------------------- The bug does not repro on Flame 2.0 engineering build with shallow flash. Actual result: As The Guardian app loads, there is a progress indicator at the top of the screen. When swiping down from the top of the screen, the status bar appears and the user can pull down the notifications page with a second swipe. The rocketbar does not appear on the app, though that could be because the old webpage UI is being used. BuildID: 20141021133536 Gaia: 812ae91c9708a9116cdb2d15cc02a43ded862a78 Gecko: f92e54a91038 Platform Version: 32.0 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Flags: needinfo?(jmercado)
Keywords: qawanted
Not marking this issue as a regression because Rocketbar wasn't as major of a function in 2.0.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmercado) → needinfo?(ktucker)
(In reply to Alberto Pastor [:albertopq] from comment #7) > Apart from the progress bar problem, I cannot see the statusbar when pulling > down the rocketbar. Adding qawanted for making sure that's only happening in > master. Yep it doesn't show up on 2.1 :(
(In reply to Eric Pang [:epang] from comment #5) > (In reply to Eric Pang [:epang] from comment #4) > > (In reply to Alberto Pastor [:albertopq] from comment #3) > > > Is there any spec available about this? Thanks! > > > > Hey Francis, can we get your help for the ixd on this? > > > > I can see the need for a progress bar for some apps. But for others like > > Huff Post is it needed? From the looks of the screen it looks like the app > > already has it's own loading bar built in. Is there a way we can check if > > it's needed? > > Francis, disregard my last comment, for some reason I was testing with Huff > Post instead of Guardian! > > But this brings up a separate question :). > > When the rocket bar is expanded the progress bar is shown below. But when > the app is in full screen currently no progress bar is shown when loading > pages. Should the progress bar should at the top of the screen? I'd say we don't need this in the case of full-screen apps, as they're effectively indicating that they want to have full control over the UI.
Flags: needinfo?(fdjabri)
(In reply to Alberto Pastor [:albertopq] from comment #3) > Is there any spec available about this? Thanks! The IxD spec is available at: https://mozilla.box.com/s/vudi13ucue2ok0s3pfx8 The behavior should be: first swipe downs reveals status bar, second swipe brings up the utility tray.
I believe for fullscreen apps that also request navigation chrome we do not show the statusbar, as it's baked into the fullscreen rocketbar. The only bug here is the placement of the progress bar.
We should write a test here which stops the page from loading, and verifies the position of the progress bar. We should probably also do this for normal websites as well. Perhaps we can just modify this test: https://github.com/KevinGrandon/gaia/blob/master/apps/system/test/marionette/browser_fullscreen_navigation_chrome_test.js
As per Kevin's comment, the statusbar not being shown is the right behavior. This patch moves the progress bar on fullscreen apps.
Attachment #8510185 - Flags: review?(kgrandon)
Component: Gaia::System → Gaia::System::Browser Chrome
Very confusing UX.
blocking-b2g: 2.1? → 2.1+
Comment on attachment 8510185 [details] [review] Link to Pull Request: https://github.com/mozilla-b2g/gaia/pull/25441 Looks good, but I left some feedback about the test on github. Please rebase against master, and re-flag me for review - I just want to make sure this test passes several times so we don't introduce an intermittent test. Thanks!
Attachment #8510185 - Flags: review?(kgrandon) → feedback+
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Target Milestone: --- → 2.1 S8 (7Nov)
Comment on attachment 8510185 [details] [review] Link to Pull Request: https://github.com/mozilla-b2g/gaia/pull/25441 Finally... green build!
Attachment #8510185 - Flags: review?(kgrandon)
Comment on attachment 8510185 [details] [review] Link to Pull Request: https://github.com/mozilla-b2g/gaia/pull/25441 I think we can land this for now because it's green. Please make the commit message more descriptive before landing. Thanks!
Attachment #8510185 - Flags: review?(kgrandon) → review+
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment on attachment 8510185 [details] [review] Link to Pull Request: https://github.com/mozilla-b2g/gaia/pull/25441 [Approval Request Comment] [Bug caused by] (feature/regressing bug #): - [User impact] if declined: Progressbar shown in the wrong place on fullscreen apps, which is very confusing [Testing completed]: ADded integration tests [Risk to taking this patch] (and alternatives if risky): low risk. Css only and added tests. [String changes made]: -
Attachment #8510185 - Flags: approval-gaia-v2.1?(fabrice)
Flags: in-testsuite+
Attachment #8510185 - Flags: approval-gaia-v2.1?(fabrice) → approval-gaia-v2.1+
Issue still occurs in Flame 2.1 and Flame 2.2 Actual Result: Pulling down search bar while page is loading briefly reveals loading bar at top of screen before it relocates to position below search bar. No status bar is seen. Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash) BuildID: 20141031001201 Gaia: f89c7b12c36572262c9ea76058694a139b1a8634 Gecko: 50d48f8a04c7 Gonk: 48835395daa6a49b281db62c50805bd6ca24077e Version: 34.0 (2.1) Firmware: V188 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash) BuildID: 20141031061804 Gaia: a07994714f0552f89801d6097982308d8b0a1ee1 Gecko: 6bd2071b373f Gonk: 48835395daa6a49b281db62c50805bd6ca24077e Version: 36.0a1 (2.2) Firmware Version: v188 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?][failed-verification]
Flags: needinfo?(ktucker)
(In reply to Brogan Zumwalt [:BroganZ] from comment #23) > Issue still occurs in Flame 2.1 and Flame 2.2 > > Actual Result: Pulling down search bar while page is loading briefly reveals > loading bar at top of screen before it relocates to position below search > bar. No status bar is seen. > Statusbar not seen is the expected behavior as per comment #13. Regarding the progressbar, it should be shown just bellow the rocketbar chrome. Is not that what is happening? Thanks!
Flags: needinfo?(bzumwalt)
For a brief moment when page is loading the progressbar is shown above the rocketbar chrome. Youtube link to video showing issue (slowed down at point where issue occurs): http://youtu.be/onUrLUdsxcM Regarding status bar, should have been more clear. I know it is the expected result, just wanted to be thorough.
Flags: needinfo?(bzumwalt)
I see... I'll work on fixing that. Thanks!
Depends on: 1093692
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
Attached video video of issue verify
This issue has been verified successfully on Flame 2.1 See attachment: verify_video.MP4 Reproducing rate: 0/5 Flame 2.1 versions: Gaia-Rev afdfa629be209dd53a1b7b6d6c95eab7077ffcd9 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/dc3018cbdbe6 Build-ID 20141123001201 Version 34.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141123.035029 FW-Date Sun Nov 23 03:50:40 EST 2014 Bootloader L1TC00011880
Verified the bug is fixed on 2.2 Flame Progress-bar is showed below the rockerbar search But repros on Flame 2.1 Progress-bar is showed at the top of the screen in fullscreen apps, see the YouTube video (http://youtu.be/Dh4ioOAky4k) does NOT repro on: Device: Flame 2.2 (319mb)(Kitkat Base)(Shallow Flash) BuildID: 20141124100136 Gaia: aad40f6d6eb8f626c6a20db55b9f00d2e832f113 Gecko: be4ba3d5ca9a Version: 36.0a1 (2.2 Master) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 DOES repro on: Flame 2.1 (319mb)(Kitkat Base)(Shallow Flash) BuildID: 20141124094013 Gaia: 8ae086c39011bc8842b2a19bb5267906fa22345a Gecko: ebbd5c65c3c1 Version: 34.0 (2.1) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+][failed-verification] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Flipping 2.1 flag back to fixed based on comment 28
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage?][failed-verification]
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage+][failed-verification] → [QAnalyst-Triage+]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: