User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070530 Minefield/3.0a5pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070530 Minefield/3.0a5pre In the attached test case, an SVG image is contained within a frame with an explicitly-specified frame border. When the image initially renders, a spurious horizontal line is present. Scrolling the image causes it to become covered in horizontal lines. Reproducible: Always Steps to Reproduce: 1. Open the attached test.html 2. Click the button "Click Me". 3. A popup window appears with two frames in which frame1 contains another "Click Me" button. click this. 4. An SVG image appears in frame 2. 5. Scroll the image up and down. Actual Results: After step 4, the SVG image has a spurious horizontal line. After step 5 the SVG image is covered in horizontal lines. Expected Results: The SVG should not have any horizontal lines on it. Essential to the test case are (i) Use of a popup window (OK if frameset.html is loaded directly); (ii) Use of an explicitly-specified frame border (OK with default border); (iii) Loading the SVG in frame 2 from an on-click event in frame 1 (OK if loaded by specifying src="frame2.html" in the frameset). Regression in the last few weeks.

It regressed in two steps. First you see a black bar on top. The bug that caused this black bar is in this range: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1179885660&maxdate=1179892439 The second regression range (with the bug that caused the lines) is: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1180146780&maxdate=1180152899

Taking; I haven't fully figured out what's going on, but I'll try to have a patch soon.

Okay, I have a fix for the black border; I'll post it in a bit once I sort out the patch. There's an issue here with the painting of the frameset border (you should be able to reproduce by dragging a window over the page). There's also a minor issue with events which I don't have a patch for at the moment. I think the border is somehow thicker than its visible part, and is therefore catching events it shouldn't. That, combined with the painting code for the border being broken for unusual translations, and the transparency of the frames, leads to this painting bug. The third issue is the scrolling; I think the scrolling code is getting messed up by not taking into account the offset getting used for painting. (Ugh, having all these widgets around makes getting rounding right a mess...)

Don't know if it's important but the thing about having to be in a popup window is a red herring. The requirement is only that the window is NOT MAXIMISED. You can see this by opening the frameset.html (https://bugzilla.mozilla.org/attachment.cgi?id=266746) directly. You only see the bug if the firefox window you open it in is NOT maximised.

Some corrections to the view-widget offset handling.

Checked in.

This patch has fixed the original test case but I'm still seeing the problem in other test cases. Attaching a revised frame1.html. To recreate the issue 1) Open test.html. 2) Click "Click Me" (popup opens). 3) Click "Click Me" in top frame of popup. 4) Click "Resize Me" in top frame of popup. 5) Scroll bottom frame of popup up and down.

New frameset source, required to reference new frame1

New test HTML source, required to reference new frameset.

I can't reproduce. Not sure what's going on... can you post a screenshot with a trunk build from today?

Here's a screenshot. One thing I did notice is that when I switch to another window and back again most of the horizontal lines go away although there is still a single horizontal line at the top of the SVG

Actually the single line above the SVG appears as soon as I click "Resize me" (see attached). Then when I scroll the frame that line seems to generate lots more lines. After switching to another window and back again those extra lines produced during scrolling have gone and I just have the single line. Also, if I click "resize me" before "click me" everything works.

(In reply to comment #14) (In reply to comment #15) (In reply to comment #16) Duncan: it'd be slightly less clutter/bugspam if you attached multi-file testcases as jars (zips). :-) Basically, you get the testcase working using only relative paths, as a set of files, and then you dump them into a zip file, in exactly the relative directory structure they have on disk. Then, to use the testcase, you create a jar URL pointing to the file which runs the entire testcase. For example, if "foo.html" in a folder "foo" in the zip is the file which demonstrates the bug, you'd provide a URL like this: jar:the-zip-file-url.zip!/foo/foo.html The only downside to this is that you can't run the test cross-browser, as at the moment I don't believe any other browsers support jar URLs.

Thanks, I didn't know I could do that. It is indeed a pain to have to re-attach and obsolete lots of files when another attachment changes.

Hmm, I can't reproduce with the testcase you uploaded. Are you sure you uploaded the right thing? Are there any tweakable parameters you could expose in the testcase?

I get it every time, by clicking on the https://bugzilla.mozilla.org/attachment.cgi?id=270240 and the "Click Me" and then "Click Me" in the popup and then "Resize Me" in the popup and then scroll the bottom frame. Does the popup window resize itself to be narrower when you click "Resize me" ? If not, try re-sizing the window manually.

URI is jar:https://bugzilla.mozilla.org/attachment.cgi?id=270335!/test.html

Hmm, I can reproduce in a nightly, but not in my build; I think I actually have a patch for this issue in my tree.

That's a relief. I'll give it another go as soon as you have the patch into a nightly.

This bug here caused Bug 386507, backing out the patch locally fixed it.

You're going to hate me for this but here goes. The effect I was seeing before, black lines on scrolling, has gone in the nightly from 2006-07-02. But I'm seeing something else now, a little harder to reproduce. Using the same test case, jar:https://bugzilla.mozilla.org/attachment.cgi?id=270335!/test.html, perform these steps 1) Click me 2) Click me in the popup top frame 3) drag the frame border downwards until most of the blue square is off the bottom of the screen 4) scroll the bottom frame up by pressing and holding the down arrow on the scrollbar. When I do this I see white horizontal lines across the image, see attached.

(In reply to comment #29) > You're going to hate me for this but here goes. Well, the fact that all these bugs keep popping up is annoying, but please keep doing it; it's better to have someone to poke holes in my patches than for bugs to ship. I'll have to investigate a bit more to figure out what's going on here.

(I'm still building with this, but I'm pretty sure this is the issue.) Multiplying by the inverse is sufficient for general floating-point arithmetic; however, we are extremely sensitive to rounding here.

Patch checked in; any more issues?

Looking good from here now. Have tried all three variants of the test case and also my original app and they all seem to be fine.

Can this be closed now?

Yeah, I think so. Any additional issues can go into other bugs.