[Webkit-unassigned] [Bug 15238] New: Odd horizontal scrolling amount corrupts gif rendering in JavaScript context

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=15238

           Summary: Odd horizontal scrolling amount corrupts gif rendering
                    in JavaScript context
           Product: WebKit
           Version: 522+ (nightly)
          Platform: Macintosh Intel
               URL: http://www.nytimes.com/
        OS/Version: Mac OS X 10.4
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P3
         Component: JavaScriptCore
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: norm at agorics.com


I have seen this only with ephemeral ads which seldom last long enough to last
until report is read.
See two files at (http://cap-lore.com/bug/b2/b1.tiff) and
(http://cap-lore.com/bug/b2/b2.tiff)
They are made by the grab Utility.
One can get from either to the other buy scrolling the image vertically out of
the window, scrolling an odd number of pixels horizontally, and then scrolling
the image back in vertically.

I think that the following html is what caused the image:
It came from the page at <http://www.nytimes.com/> at about 23:00 on 2007, Sept
18, PDT.

<div class="columnGroup" id="HPMiddle">
<!-- ADXINFO classification="bigad" campaign="Amex-STS-659605-nyt1"--><SCRIPT
language='JavaScript1.1'
SRC="http://ad.doubleclick.net/adj/N553.newyorktimes.com/B2348401.13;sz=300x250;ord=2007.09.19.05.42.55?">
</SCRIPT>
<NOSCRIPT>
<A
HREF="http://ad.doubleclick.net/jump/N553.newyorktimes.com/B2348401.13;sz=300x250;ord=2007.09.19.05.42.55?">
<IMG
SRC="http://ad.doubleclick.net/ad/N553.newyorktimes.com/B2348401.13;sz=300x250;ord=2007.09.19.05.42.55?"
BORDER=0 WIDTH=300 HEIGHT=250 ALT="Click Here"></A>
</NOSCRIPT>
</div>

10 minutes later the same page shows a different ad in the same position.
The same fault happens with that ad too.

A similar but different bug is in Firefox.
I am running my screen with 16 bit pixels.
(about 5 in 10 tries are bad)
With 32 bit pixels the problem goes away (10 in 10 tries are good).
The same thing with Firefox.

I quit the browser, downloaded the nightly build of Web kit, and then went back
to the same page; the problem persists.
I rebooted the Mac and relaunched Safari; the problem persists.
I launch Firefox 2.0.0.6; a similar but different problem occurs.
I cannot make it fail with Opera 9.20 build 3669 or MS Explorer 5.2.

In Safari scrolling horizontally, while keeping the pixels in the window,
neither causes the corruption nor repairs it.
In Firefox, however, such horizontal scrolling causes the problem (50% of the
time) or fixes it (50% of the time).
I think I have confirmed that it depends on whether scrolling amount, in
pixels, is even or odd.
It is as if the pixel copying due to scrolling were at a different level of
rendering.
The bug may not be shared between Firefox and Safari.

I think I can scroll horizontally one pixel at a time.
If I am right then I deduce that odd horizontal scroll positions have the
problem and even ones do not, or vice versa.
It looks like a byte ordering problem, or really an ordering of 16 bit shorts.
Perhaps pixels are copied 32 bits at a time between areas with different
ordering conventions.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.