Closed
Bug 919039
Opened 11 years ago
Closed 11 years ago
Pinch to Zoom fails on most areas of the content on http://mozilla.github.io/qa-testcase-data/webapi/webrtc/
Categories
(Core :: Panning and Zooming, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 925902
blocking-b2g | koi+ |
People
(Reporter: jsmith, Assigned: kats)
References
Details
(Keywords: regression)
Attachments
(1 file)
213.27 KB,
text/plain
|
Details |
Build: 9/20/2013 Master
Device: Buri
STR
1. Go to http://mozilla.github.io/qa-testcase-data/webapi/webrtc/ in the browser
2. Try to pinch to zoom
Expected
You should be able to zoom in and out of content easily.
Actual
In many cases, I cannot get pinch to zoom to allow me to zoom in and out. In some small chances, I've seen pinch to zoom work, but in most cases, it fails.
Reporter | ||
Updated•11 years ago
|
blocking-b2g: --- → koi?
Keywords: regression,
regressionwindow-wanted
Reporter | ||
Comment 1•11 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #0)
> Created attachment 808008 [details]
> Logcat
>
> Build: 9/20/2013 Master
> Device: Buri
One fix - Build should be 9/20/2013 1.2, not Master.
Comment 2•11 years ago
|
||
This is working here on the given test page, closing wfm until we have reproducable steps
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 3•11 years ago
|
||
(In reply to Dale Harvey (:daleharvey) from comment #2)
> This is working here on the given test page, closing wfm until we have
> reproducable steps
No. This is obvious to reproduce. And if you are having trouble to reproduce, ask first please. There's obvious perf regressions around APZC, so it's not surprising this is present.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Reporter | ||
Comment 4•11 years ago
|
||
See if someone get better STR here. I know I saw this after using the browser for daily testing, but apparently upon a restart of my phone pinch to zoom now works on the test page, although the perf still really sucks on it (which can be tracked separately).
Keywords: regressionwindow-wanted → steps-wanted
Reporter | ||
Updated•11 years ago
|
blocking-b2g: koi? → ---
Reporter | ||
Comment 5•11 years ago
|
||
Removing nom until we figure out what reproduced this. Basically, start using the browser for a while and use pinch to zoom as you surf web content. See if pinch to zoom degrade over time.
On Friday, I saw this get to the point where pinch to zoom stopped working consistently. Now, it's fine after a restart. Weird.
might be related to bug 915592 ? Not sure. I agree we should try digging to see if there's extra steps that needs to be done to reach this issue.
Reporter | ||
Comment 7•11 years ago
|
||
Here's a video showing when this reproduces - http://www.youtube.com/watch?v=FfHcHK7OpvQ
Reporter | ||
Updated•11 years ago
|
QA Contact: jsmith
Reporter | ||
Comment 9•11 years ago
|
||
That was quick - the dupe shows an alternative STR to use to reproduce this bug. Let's try getting the regression window here. Use the STR that works the best - if the dupe works better, use that.
blocking-b2g: --- → koi?
Keywords: steps-wanted → regressionwindow-wanted
Reporter | ||
Updated•11 years ago
|
QA Contact: jsmith
Updated•11 years ago
|
blocking-b2g: koi? → koi+
Comment 10•11 years ago
|
||
The window for this issue appears to be between 09/05 and 09/06:
Occurs on-
Buri Build ID: 20130906040204
Gecko: http://hg.mozilla.org/mozilla-central/rev/ab5f29823236
Gaia: 94e5f269874b02ac0ea796b64ab995fce9efa4b3
Platform Version: 26.0a1
Does not occur-
Buri Build ID: 20130905040201
Gecko: http://hg.mozilla.org/mozilla-central/rev/77ed46bf4c1a
Gaia: ec885264d885d877d68980c0227058231f18ad09
Platform Version: 26.0a1
In build 09/05 the page was scrollable and I was able to pinch to zoom without issues, but on 09/06 it appears the trouble scrolling started to occur.(cnn.com was used)
Keywords: regressionwindow-wanted
Updated•11 years ago
|
Whiteboard: [systemsfe]
Reporter | ||
Comment 11•11 years ago
|
||
kats - Can you look into this bug? We're looking to find an assignee for this blocker. This looks related to APZC, so I'm wondering if you could take this.
Flags: needinfo?(bugmail.mozilla)
Assignee | ||
Comment 12•11 years ago
|
||
Yeah I can look at this. Do you know if it happens on master as well? Or is it 1.2 only?
Assignee: nobody → bugmail.mozilla
Flags: needinfo?(bugmail.mozilla)
Reporter | ||
Comment 13•11 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #12)
> Yeah I can look at this. Do you know if it happens on master as well? Or is
> it 1.2 only?
It's definitely on 1.2. I'll mark qawanted for someone to check if it reproduces on master right now.
Keywords: qawanted
Comment 14•11 years ago
|
||
Reproduces on master too.
Buri
Gaia 1ac6749e36424124493a1b4c7534f298789bdffd
SourceStamp 8f08240128c8
BuildID 20131004040203
Version 27.0a1
Keywords: qawanted
Reporter | ||
Updated•11 years ago
|
Component: Gaia::Browser → Graphics
Product: Boot2Gecko → Core
Version: unspecified → 26 Branch
Assignee | ||
Comment 15•11 years ago
|
||
I started looking into this bug this morning. The dupe (bug 919750) is really an INVALID bug because the CNN.com mobile site (which is what I get on my GP device, and what is visible in the video on that bug) sets a meta viewport tag like so:
width=device-width, initial-scale=1, maximum-scale=1, user-scalable=0
which makes the page not zoomable. If the page *is* zoomable, that's a bug. The behaviour I'm seeing and what is reported in bug 919750 is expected.
I also tried to reproduce zooming issues on the github.io page linked to in this bug. For the most part I was able to zoom in and out fine, although I did run into periods where zooming didn't work on some parts of the page. I have the layer borders debug option turned on, and I could see that when the zooming didn't work, it was because the layer wasn't updating the way it shouldn't be, and my pinch would fall outside the layer. When this happened, I could also see the text render blurry when I zoomed in, indicating that Gecko was not repainting the new content. I'm not sure yet why Gecko stalled like that (for a period of ~10 seconds) but I will try to dig into it.
Assignee | ||
Updated•11 years ago
|
Component: Graphics → Panning and Zooming
Assignee | ||
Comment 16•11 years ago
|
||
I've seen this happen a few more times now, while I have the profiler running. The profile shows that both the parent and child process are not really doing anything, they are idle and ready to process messages. It's looking more like the message to update Gecko gets lost or dropped or something, and then later some other action or delay will trigger a new message which will cause the paint. I will probably need to instrument the code more to track the repaint messages getting sent and see if any of them are getting dropped for some reason.
Assignee | ||
Comment 17•11 years ago
|
||
I tracked down the problem I was seeing and filed bug 925902 for it. With the patch on that bug applied I can no longer reproduce anything that matches the description of this bug. Either all of the symptoms in this bug were caused by that one, or I need better STR - I can't do much more on this bug otherwise.
Depends on: 925902
Reporter | ||
Comment 18•11 years ago
|
||
removing systemsfe - this is being actively tracked by gfx team
Whiteboard: [systemsfe]
Assignee | ||
Comment 19•11 years ago
|
||
See comment 17. Are you still able to repro the problem on the latest nightly, and if so, can you provide more detailed STR?
Flags: needinfo?(jsmith)
Reporter | ||
Comment 20•11 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #19)
> See comment 17. Are you still able to repro the problem on the latest
> nightly, and if so, can you provide more detailed STR?
I'll have someone look into this. QA Wanted for a retest.
Flags: needinfo?(jsmith)
Keywords: qawanted
Reporter | ||
Comment 21•11 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #20)
> (In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #19)
> > See comment 17. Are you still able to repro the problem on the latest
> > nightly, and if so, can you provide more detailed STR?
>
> I'll have someone look into this. QA Wanted for a retest.
Specifically on master + central, as that's where the patch is question landed.
Updated•11 years ago
|
QA Contact: dwatson → nkot
Comment 22•11 years ago
|
||
Able to zoom in and out of content easily on Buri 10/17 m-c build,
have seen other issues such as black screen flickering or temporary screen freezes, but no problem with zooming in particular (these other issues are being tracked in other bugs.)
tested on:
http://mozilla.github.io/qa-testcase-data/webapi/webrtc/
http://people.mozilla.com/~nhirata/html_tp/
https://wiki.mozilla.org/Main_Page
//still not able to zoom in-out on cnn.com, but per comment 15 is not a zoomable page.
BuildID: 20131017040202
Gaia: 616e87af0133496620aea89f21ca5d37acedf466
Gecko: 423b9c30c73d
Version: 27.0a1
Keywords: qawanted
Reporter | ||
Comment 23•11 years ago
|
||
Black flickering is covered by a different bug. The screen freezes sounds bad - can you file a separate bug for that?
Based on the analysis here, this appears to be fixed by bug 925902, so I'm duping forward to that bug.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
No longer depends on: 925902
Resolution: --- → DUPLICATE
Comment 24•11 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #23)
> Black flickering is covered by a different bug. The screen freezes sounds
> bad - can you file a separate bug for that?
>
sure, will try to repro and file a bug
Comment 25•11 years ago
|
||
filed Bug 928584 for tracking freezes on zooming
You need to log in
before you can comment on or make changes to this bug.
Description
•