Closed
Bug 494715
Opened 14 years ago
Closed 14 years ago
When panning the content and switching tab, viewport can be wrong
Categories
(Firefox for Android Graveyard :: Panning/Zooming, defect)
Firefox for Android Graveyard
Panning/Zooming
Tracking
(Not tracked)
VERIFIED
FIXED
fennec1.0b2
People
(Reporter: vingtetun, Assigned: vingtetun)
References
Details
Attachments
(2 files, 2 obsolete files)
806 bytes,
patch
|
bcombee
:
review+
|
Details | Diff | Splinter Review |
516 bytes,
patch
|
mfinkle
:
review-
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090522 Minefield/3.6a1pre Build Identifier: When panning to the bottom of some website and going to another tab I see only the checkerboard, or depending on the amount panned a part of the web site and the checkerboard Reproducible: Always Steps to Reproduce: 1.Open a new tab 2.go to http://www.malaysiabest.net/2005/09/27/the-soup-that-guarantees-to-make-you-burppp/ 3.pan to the bottom 4. Switch back to the previous tab Actual Results: The canvas area show the checkerboard Expected Results: the website ! When we click on a tab, the ChromeInputModule of InputHandler catch the click and start a dragging session this prevent the call to viewportUpdate that put the right info to the inner struct of WidgetStack. Manually calling ws.dragStop() in browser.js#selectedTab correct the problem.
Assignee | ||
Comment 1•14 years ago
|
||
Assignee | ||
Comment 2•14 years ago
|
||
Sorry, I don't want to put ws.dragStop in the try/catch (there is no reason)
Attachment #379481 -
Attachment is obsolete: true
Comment 3•14 years ago
|
||
(In reply to comment #0) > When we click on a tab, the ChromeInputModule of InputHandler catch the click > and start a dragging session this prevent the call to viewportUpdate that put > the right info to the inner struct of WidgetStack. > Manually calling ws.dragStop() in browser.js#selectedTab correct the problem. Can we fix the ChromeInputHandler? I'd rather fix the real problem.
Assignee | ||
Comment 4•14 years ago
|
||
(In reply to comment #3) > Can we fix the ChromeInputHandler? I'd rather fix the real problem. Yep! It seems that there is two fix depending on the role of ws.dragStart in the ChromeInputModule : // grab all events until we stop the drag ws.dragStart(sX, sY); Firstly the comment seems to be not relevant (has moved between revision and the code probably came from the panning module), and I'm not sure there is any needs for calling the ws.startDrag on chrome input event? If that true we can simply remove this the two lines (comment and function call) and this simple fix resolve the problem (We're not anymore considered in a dragging state for the ws and viewportUpdate is called). Otherwise if the called to dragStart is needed ( for what? ), balanced him in _dragStop (InputHandler.js#288) correct the problem but can lead to quickly see the checkerboard.
Comment 5•14 years ago
|
||
There are other patches in my own queue that also change this code. I'd like to see those finished and landed and then retest this bug.
Assignee | ||
Comment 6•14 years ago
|
||
Ben, any news on the patches from your queue?
Assignee | ||
Comment 7•14 years ago
|
||
Comment 8•14 years ago
|
||
Because endUpdateBatch() doesn't update the viewport even if "aForceRedraw" is specified, the base position of the viewport box (#canvasbox) moves unexpectedly.
Attachment #383170 -
Flags: review?(mark.finkle)
Comment 9•14 years ago
|
||
This blocks bug 476703.
Assignee | ||
Comment 10•14 years ago
|
||
(In reply to comment #8) > Created an attachment (id=383170) [details] > patch v1 > > Because endUpdateBatch() doesn't update the viewport even if "aForceRedraw" is > specified, the base position of the viewport box (#canvasbox) moves > unexpectedly. Yes. It's what I've said above, we're in a dragging session, so viewportUpdate is not called.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•14 years ago
|
Attachment #383170 -
Flags: review?(mark.finkle)
Comment 11•14 years ago
|
||
I saw a different version of this problem with picking pages from the awesome bar using the touch/mouse. If I went to my iframes test page, panned down, then went to google news, I'd get my viewport completely removed.
Comment 12•14 years ago
|
||
Comment on attachment 381066 [details] [diff] [review] Remove ws.dragStart This change makes a lot of sense. When we're dragging in chrome, we're not going to ever make calls to ws.panBy or anything to reposition the canvas, and this dragStart won't be correctly paired with dragEnd. Nothing in chrome handling has any other ws calls.
Attachment #381066 -
Flags: review+
Comment 13•14 years ago
|
||
Comment on attachment 383170 [details] [diff] [review] patch v1 Let's try this with the "remove ws.dragStart" patch first.
Attachment #383170 -
Flags: review-
Updated•14 years ago
|
Attachment #379482 -
Attachment is obsolete: true
Comment 14•14 years ago
|
||
pushed http://hg.mozilla.org/mobile-browser/rev/94b547d119a9
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment 15•14 years ago
|
||
Had some checkin problem backout: https://hg.mozilla.org/mobile-browser/rev/fdd6139cb846 push: https://hg.mozilla.org/mobile-browser/rev/9de9d605a6b1
Updated•14 years ago
|
Assignee: nobody → 21
Hardware: Other → All
Target Milestone: --- → B2
Comment 16•14 years ago
|
||
verified FIXED on builds: Mozilla/5.0 (Macintosh; U; Intel Mac OSX 10.5; en-US; rv:1.9.2a2pre) Gecko/20090808 Fennec/1.0b3pre and Mozilla/5.0 (X11; U; Linux armv6l; en-US; rv:1.9.3a1pre) Gecko/20090820 Fennec/1.0b3pre
Status: RESOLVED → VERIFIED
Updated•13 years ago
|
Component: General → Panning/Zooming
You need to log in
before you can comment on or make changes to this bug.
Description
•