Closed
Bug 520074
Opened 15 years ago
Closed 15 years ago
Thumbnail in left sidebar is bumped over by right sidebar
Categories
(Firefox for Android Graveyard :: General, defect)
Firefox for Android Graveyard
General
Tracking
(fennec1.0+)
VERIFIED
FIXED
fennec1.0
Tracking | Status | |
---|---|---|
fennec | 1.0+ | --- |
People
(Reporter: tyson, Assigned: vingtetun)
Details
Attachments
(2 files, 1 obsolete file)
85.41 KB,
image/jpeg
|
Details | |
1011 bytes,
patch
|
stechz
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 Build Identifier: 1.0b4 When one pulls over the right sidebar, loads a new page, and pulls over to the left sidebar, the screenshot in the left sidebar will have a white strip down the right side where the right sidebar was when the page was loaded. Reproducible: Always Steps to Reproduce: 1.Open Fennec (I used the OS X version 1.0b4) 2.Pull the screen to the left, displaying the right sidebar. 3.Go to a new page (preferably with a non-white background so the flaw is more visible) 4.Slide right to expose the left toolbar, showing the screenshot with a white bar where the right bar was when the page was loaded. Actual Results: A white bar was rendered on the screenshot on the right side where the right toolbar was when the page was loaded. Expected Results: Should have taken the screenshot of the page at full-width without the right-sidebar placeholder MacBook Pro 3.1, 2.2GHz Intel Core 2 Duo, 2GB memory, OS X 10.5.8 (Leopard, up to date)
Reporter | ||
Comment 1•15 years ago
|
||
Coincidentally on the Acid3 test, but happens on all other pages.
Comment 2•15 years ago
|
||
This happens on slashdot.org on build: Mozilla/5.0 (X11; U; Linux armv7l; en-US; rv:1.9.2b1pre) Gecko/20091008 Fennec/1.0b4
Status: UNCONFIRMED → NEW
tracking-fennec: --- → ?
Ever confirmed: true
Flags: wanted-fennec1.0?
OS: Mac OS X → All
Hardware: x86 → All
Updated•15 years ago
|
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Comment 3•15 years ago
|
||
Ah, stuart this is still happening on build: Mozilla/5.0 (Windows; U; WindowsCE 5.2; en-US; rv:1.9.2b1pre) Gecko/20091023 Fennec/1.0a4pre and Mozilla/5.0 (X11; U; Linux armv7l; en-US; rv:1.9.2b1pre) Gecko/20091023 Fennec/1.0b5pre and Mozilla/5.0 (X11; U; Linux armv6l; en-US; rv:1.9.3a1pre) Gecko/20091023 Fennec/1.0b5pre You have to open the right sidebar, go to the acid 3 test. after page load, then go to the left sidebar
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Updated•15 years ago
|
tracking-fennec: ? → 1.0+
Summary: Screenshot in left sidebar is bumped over by right sidebar → Thumbnail in left sidebar is bumped over by right sidebar
Reporter | ||
Comment 4•15 years ago
|
||
For me, it's not just on Acid3; it's on any webpage.
Assignee | ||
Comment 5•15 years ago
|
||
The steps to repro has changed since now we hide the sidebars when a new page is loaded : * go to a page with a black background (e.g: http://vingtetun.org/todo/) * go to the awesome bar and load p.m.o * before it has finished loading pan to the left to show the right sidebar * wait until it finished loading and look at the tab thumbnail I've just change one line in renderToCanvas since the only caller without a src parameter is tabs.xml.
Assignee: nobody → 21
Attachment #414744 -
Flags: review?(webapps)
Assignee | ||
Comment 6•15 years ago
|
||
Benjamin, if you prefer we could add use a custom parameter in tabs.xml but I'll be happy to avoid the use of Browser in the binding.
Comment 7•15 years ago
|
||
> - vr.x = cr.left;
> + vr.x = 0;
> vr.y = cr.top;
Should we set vr.t to zero too? Just to be safe?
Assignee | ||
Comment 8•15 years ago
|
||
(In reply to comment #7) > > - vr.x = cr.left; > > + vr.x = 0; > > vr.y = cr.top; > > Should we set vr.t to zero too? Just to be safe? Nope, otherwise the notifications are visible (or at least the size taken by the notifications)
Comment 9•15 years ago
|
||
(In reply to comment #8) > Nope, otherwise the notifications are visible (or at least the size taken by > the notifications) This looks to be false (Vivian and I have been testing). Vivian is double checking, but the result matches my understanding of renderRectToCanvas. srcRect is expected to be in viewport coordinates, where the origin is at the upper left corner of the upper left tile. So 0, 0 should always start at the tiles and never at the notifications. Using the critical rect is the wrong idea here because it factors in sidebars and notifications into its x and y. If we want a thumbnail of where the viewport "camera" is located, we should use bvs's left and top coordinates. If we just want the top of the page, use 0, 0. I'm glad we are getting to the bottom of this, the inconsistent thumbnails have been annoying me for some time. :)
Assignee | ||
Comment 10•15 years ago
|
||
After seeing on IRC I've done it the wrong way! This patch should do the trick.
Attachment #414744 -
Attachment is obsolete: true
Attachment #415175 -
Flags: review?(webapps)
Attachment #414744 -
Flags: review?(webapps)
Comment 11•15 years ago
|
||
Comment on attachment 415175 [details] [diff] [review] Patch v0.2 I can't find any webpage where the left and top are not 0, 0 when the snapshot is taken (for instance http://people.mozilla.org/~bcombee/fennec/iframe-test.html#iframe-area should render thumbnail in the middle of page). This was happening before and the patch fixes what it should. r+
Attachment #415175 -
Flags: review?(webapps) → review+
Comment 12•15 years ago
|
||
pushed: https://hg.mozilla.org/mobile-browser/rev/85eb06d76c60
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → Post-B5
Comment 13•15 years ago
|
||
verified FIXED on builds: Mozilla/5.0 (Windows; U; Window3sCE 5.2; en-US; rv:1.9.2b5pre) Gecko/20091201 Namoroka/3.6b5pre Fennec/1.0a4pre and Mozilla/5.0 (X11; U; Linux armv7l; Nokia N900; en-US; rv:1.9.2b5pre) Gecko/20091201 Firefox/3.6b5pre Fennec/1.0b6pre and Mozilla/5.0 (X11; U; Linux armv6l; Nokia N8xx; en-US; rv:1.9.3a1pre) Gecko/20091201 Firefox/3.7a1pre Fennec/1.0b5
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•