Closed Bug 1091069 Opened 6 years ago Closed 6 years ago

Progress bar has disappeared

Categories

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

defect

Tracking

(blocking-b2g:2.0M+, b2g-v2.0 unaffected, b2g-v2.0M unaffected, b2g-v2.1 verified, b2g-v2.2 verified)

VERIFIED FIXED
2.1 S8 (7Nov)
blocking-b2g 2.0M+
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.0M --- unaffected
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: benfrancis, Assigned: apastor)

References

Details

(Keywords: regression, Whiteboard: [systemsfe])

Attachments

(5 files)

STR:
* Tap browser icon
* Type a web address
* Hit enter

Expected:
* Progress bar shows that page is loading

Actual:
* A blank white space appears where the progress bar should be
Alberto, could this have been caused by bug 1087042

QA, can we get a branch check please? I saw this on master but if this was bug 1087042 then it will reproduce on 2.1 too.
blocking-b2g: --- → 2.2?
Flags: needinfo?(apastor)
Keywords: qawanted
Whiteboard: [systemsfe]
Looks like the progress bar does display in 2.1, but there is still a slightly empty white space when it is hidden.
Issue is reproducible on Flame 2.2 master and Flame 2.1.

Observed behavior: No animated blue bar under the URL bar for the duration of loading a webpage. I had to flash to an earlier master build to look at how this bar looks like. Attaching a combined screenshot showing what this bar looks like and what the browser looks without it.

Device: Flame 2.2 Master (shallow flash)
BuildID: 20141029054810
Gaia: a9a847920b51b79c4ad4ad339f0a005777a6228c
Gecko: c6989e473f97
Version: 36.0a1 (2.2 Master)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Device: Flame 2.1 (shallow flash)
BuildID: 20141029082611
Gaia: 2099fb0df60548cf7d4afc367f5048622cc29b3e
Gecko: f02f3fbd0bb0
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Not checking 2.0 because browser2/chrome browser is not implemented on 2.0.
Attaching a logcat as requested
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Is definetely a regression of 1087042. Working on it
Assignee: nobody → apastor
Flags: needinfo?(apastor)
Sorry about that. Forgot removing a class in the selector. At least this case will be covered now.. :)
Attachment #8513748 - Flags: review?(kgrandon)
[Blocking Requested - why for this release]: Is a regression of a blocker. This should land in both branches
blocking-b2g: 2.2? → 2.1?
Comment on attachment 8513748 [details] [review]
Link to Pull Request: https://github.com/mozilla-b2g/gaia/pull/25632

LGTM. Thanks.
Attachment #8513748 - Flags: review?(kgrandon) → review+
Broken feature.
blocking-b2g: 2.1? → 2.1+
master: https://github.com/mozilla-b2g/gaia/commit/609920f4ed526d0ce994721d42b2abd12eba2dba
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Flags: in-testsuite+
Comment on attachment 8513748 [details] [review]
Link to Pull Request: https://github.com/mozilla-b2g/gaia/pull/25632

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): 1087042
[User impact] if declined: The progressbar will be only visible in fullscreen apps
[Testing completed]: Added integration tests covering this case
[Risk to taking this patch] (and alternatives if risky): Low risk. Removed class in a css selector
[String changes made]: -
Attachment #8513748 - Flags: approval-gaia-v2.1?(fabrice)
Attachment #8513748 - Flags: approval-gaia-v2.1?(fabrice) → approval-gaia-v2.1+
I'm seeing some intermittent failures for this still, I think this should clear some up.
Comment on attachment 8514542 [details] [review]
Test follow-up, adjust wait

Going to go r=me here as it's a simple testing follow-up.
Attachment #8514542 - Flags: review+
Duplicate of this bug: 1092009
Issue verified fixed on Flame 2.1 and Flame 2.2

Actual Results: Progress bar shows that page is loading

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
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Blocks: Woodduck
blocking-b2g: 2.1+ → 2.0M+
Hi Kai-Zhen,
It is reported by partner as bug 1092009
Could you please help to land on 2.0M? Thanks!
Flags: needinfo?(kli)
Hi Alberto:
 We need this patch to be uplifted on 2.0m. Do we need any rebased patch?

Thanks!!
Shawn
Flags: needinfo?(apastor)
@Alberto,
This is requested urgently by partner. Can you provide ETA date? Thanks!
I thought the devices team is taking care of landing the necessary patches on all the device specific 2.0 branches.
Flags: needinfo?(kkuo)
Flags: needinfo?(bbajaj)
Flags: needinfo?(apastor)
(In reply to Gregor Wagner [:gwagner] from comment #21)
> I thought the devices team is taking care of landing the necessary patches
> on all the device specific 2.0 branches.

Hi! Gregor,

Shawn is asking Alberto that this patch, 25632, need to be rebased for 2.0 or not?
If no rebase needed, device team can uplift to 2.0m directly. 

--
Keven
Flags: needinfo?(kkuo)
This patch was for the 2.1 system browser. If we are seeing this in 2.0 it's a different issue. This patch can not resolve something in 2.0 unless you uplift all of the system browser.
Flags: needinfo?(kli)
We need a video or screenshot of this in 2.0.
NI Marigold QA Norry,
Please also attach reproduce video in this bug. Thank you!
Flags: needinfo?(fan.luo)
Attached video verify video
Hi Josh,
We can access this website below and the progress bar can work on Woodduck 2.0m and Flame 2.0

(Website: http://www.useragentman.com/blog/2012/01/03/cross-browser-html5-progress-bars-in-depth/, Maybe you should enter the website homepage http://www.useragentman.com/, and then tap the link:"Cross Browser HTML5 Progress Bars In Depth" to load the correct page.)

Flame 2.0 build:
Gaia-Rev        fe2167fa5314c7e71c143a590914cbf3771905a8
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/241e51806687
Build-ID        20141103160206
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141103.194240
FW-Date         Mon Nov  3 19:42:51 EST 2014
Bootloader      L1TC00011880
----------------
Woodduck build:
Gaia-Rev        dd7dc2002ee180e578d3a7898c9a856245019fff
Gecko-Rev       ee1a5e900589cfb51827010127e24befbabd8043
Build-ID        20141104050313
Version         32.0
Device-Name     soul35
FW-Release      4.4.2
FW-Incremental  1415048724
FW-Date         Tue Nov  4 05:05:45 CST 2014
Flags: needinfo?(fan.luo) → needinfo?(jocheng)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
It seems like this is fine then per bug 1092009 comment 8.
Should I file a separate bug for that?(In reply to Ben Francis [:benfrancis] from comment #2)
> Looks like the progress bar does display in 2.1, but there is still a
> slightly empty white space when it is hidden.

Still seeing this, filed bug 1096301
Flags: needinfo?(bbajaj)
Blocks: Woodduck_P2
Priority: -- → P1
No longer blocks: Woodduck_P2
You need to log in before you can comment on or make changes to this bug.