Build: 2004050108 (v0.8b) Platform: 0S 10.3.3 Expected Results: When entering in resize image mode, the entire image should be scaled and displayed in the browser window. What I got: Only bottom portion of image is displayed in browser window when it's painted in image resize mode. Steps to reproduce: 1) Open the attached image in camino by drag n dropping it into a browser window 2) The image should correct scale to the window size 3) Move the cursor over the image and it will change to (+) magnify glass. Click and image will display at it's original size 4) Now, drag the window's vertical scrollbar down to the bottom of window. Click the image to re-enter image resize mode again. 5) Notice only a small bottom portion of the image is painted in the browser window. If I resize the window, it paints the window contents correctly.
Summary: A image isn't correctly painted when switch to image resize mode → A image isn't correctly painted when switching to image resize mode
OK, granted this isn't a major crash bug but I do run into this frequently when toggling back to automatic image resizing (AIR) . I believe AIR will be new feature in 0.8 that wasn't in 0.7. Based on this fact, I would like to see Camino consistantly paint the image in the window when in resize mode. Mike, any chance this can get fixed for 0.8 ? BTW, this issue doesn't occur in the latest NB's of Macho Mozilla (2004050208) or Firefox.
Priority: -- → P3
Target Milestone: --- → Camino0.8
To reproduce this issue, use the url to open the test image: http://homepage.mac.com/chrispetersen/.Pictures/smoky.jpg
Created attachment 147524 [details] Screen shot of painting issue When re-entering image resize mode, the image fails to completely paint in the browser window.
There are several bad things going on here: -The big white area -The fact that just before the bad paint, there is a flicker of the entire image; meaning that we are painting twice (which we shouldn't do even if they are both right. Similarly, when switching back to full-size, it briefly paints the small version again first. -If I switch to big, then to small again, I get a scrollbar that indicates that the page is slightly taller than the image, but moving it does absolutely nothing. The last happens even without scrolling the image at all; just two toggles of the size. Maybe unrelated, but all seem to have to do with broken scrolling.
WFM. tried in a new window, new tab, existing window. *shrug*
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
> WFM. tried in a new window, new tab, existing window. *shrug* Well, that's nice for *you*, but for the (at least) two of us for whom it's 100% reproducible, I'm re-opening. I'm seeing it with 10.3.3, and the 20040504 0.8b NB, in new window, new tab, and existing window.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
same specs, wfm. you get to debug it then ;)
Assignee: pinkerton → sbm5
Status: REOPENED → NEW
Target Milestone: Camino0.8 → Camino0.9
Hmm. I can't reproduce this problem using my steps with the 2004051715 (v0.8b) build under 10.3.3. Stuart, can you still repro this issue with this build ?
Repainting WFM with 20040516 0.8b as well. I wonder if it's actually fixed, or just a weird vanishing bug like the corrupted gifs people are seeing? I'm updating the description to reflect the part of the bug that I still see: after enlarging it, then shrinking it again, there is a scrollbar that shouldn't be there and doesn't actually scroll the page (summary was "A image isn't correctly painted when switching to image resize mode"). Is everyone else seeing that at least?
Summary: A image isn't correctly painted when switching to image resize mode → Unneeded and non-functional scrollbar appears when enlarging and re-shrinking a resized image
Target Milestone: Camino0.9 → ---
Yes, I'm seeing the vertical scroll bar too after when I switch back to image resize mode. That does look silly. Tested with 2004051715 (v0.8b) under 10.3.3.
I know I've seen a bug about this before.
Reproduced using Mozilla-Mac/1.7b. The other bug I was thinking of is bug 203500, but that seems to WFM now.
Assignee: stuart.morgan → jdunn
Component: Page Layout → Layout: Images
Product: Camino → Browser
QA Contact: core.layout.images
Version: unspecified → Trunk
WFM on http://homepage.mac.com/chrispetersen/.Pictures/smoky.jpg Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040121 build from source on Gentoo linux.
Created attachment 180864 [details] testcase 800x600 previous testcase was 1600x1200, this one 800x600
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050329 I´ve got a screen resolution of 800x600, and have all bars oben: Menu Bar, location Bar, Personal Toolbar, Site Navigation Bar, Tab Bar I´m on a ISDN connection, 8kbyte/second. Will you set this bug to OS: All, or should I file another bug for Windows? original URL: 640 kb, loads slowly, scrollbar only seen after first reload. Now I can´t reproduce that first loading, seems I have to clear my cache. Will retry later with cache cleared or another profile. http://daniel.glazman.free.fr/weblog/superHeroes-s.jpg is an image 800x600 jpeg, 80kB load or shift-Reload: vertical scrollbar without slider Reload: no scrollbar Local copy: always scrollbar seen. https://bugzilla.mozilla.org/attachment.cgi?id=180864 testcase 800x600 jpeg, 4kb: local, load, reload, shift reload: scrollbar always seen Maybe the difference is the timing? I´m on ISDN, so download time is 10 seconds vs. 0.5 seconds, based on 80kb vs. 4kb size. another observation: the scrollbar vanishes, if I collapse or expand one of the bars. Reloading after this draws it again.
(Herman In reply to comment #16) > Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050329 > > I´ve got a screen resolution of 800x600, and have all bars oben: > Menu Bar, location Bar, Personal Toolbar, Site Navigation Bar, Tab Bar > I´m on a ISDN connection, 8kbyte/second. > > Will you set this bug to OS: All, or should I file another bug for Windows? Herman, if you are asking Chris the reporter, he hasn't replied to any bugs since about 2 years.
I've seen the bug on Win98 a year ago on the testcases I made, I don't see it anymore, so resolving WFM. Feel free to reopen bug if you see it on a current browser (Firefox/Seamonkey) WFM Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20060430 SeaMonkey/1.1a
Status: NEW → RESOLVED
Last Resolved: 14 years ago → 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.