Closed Bug 1091069 Opened 10 years ago Closed 10 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.
Attached image Comparison of progress bar (deleted) —
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.
Attached file logcat of issue on Flame 2.2 master (deleted) —
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] 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+
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Flags: in-testsuite+
Comment on attachment 8513748 [details] 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+
Attached file Test follow-up, adjust wait (deleted) —
I'm seeing some intermittent failures for this still, I think this should clear some up.
Comment on attachment 8514542 [details] Test follow-up, adjust wait Going to go r=me here as it's a simple testing follow-up.
Attachment #8514542 - Flags: review+
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 (deleted) —
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.

Attachment

General

Created:
Updated:
Size: