Closed Bug 579259 Opened 12 years ago Closed 12 years ago

Black line painted in some windows


(Core :: Layout, defect)

Not set



Tracking Status
blocking2.0 --- betaN+


(Reporter: roc, Assigned: mstange)




(4 files)

Load At the bottom left corner of the window I see a 1-pixel high row of black pixels just above the status bar.
Same line visible on opening the preferences pane above the toolbar menu and disappears when you switch panes?
Go to
Scroll to the bottom.
Click on Changes
Look at the artifacts on the page.
Attached file Artifacts @ bugs.php
Hmm, I'm not seeing this on trunk today.
Bug 563878 could have affected this.
This is kind of a pain to reproduce. However, while working on another bug I saw a similar sort of line being drawn. I traced the problem down to a call to HIThemeDrawFrame, which was internally calling CGContextFillRects with the following rectangles:

  {origin = {x = 141, y = 284}, size = {width = 28, height = 1}},
  {origin = {x = -1.99741364,y = 1},size = {width = -0,height = -0}},
  {origin = {x = 1,y = 167},size = {width = 175,height = 1}}

Obviously the second rect is bogus, and the third rect is well outside the control. The behaviour is repeatable though.
Attached file testcase
If you load this testcase, make the window really small vertically, and then resize it to make it taller, you can see that the visible width of the line is equal to the height of the listbox that is not visible.

This is clearly some kind of horrific bug in HIThemeDrawFrame.
Disabling retained layers in the BasicLayerManager fixes it.

Looking at the behaviour in that case, pre-retained-layers, the "bad line" is drawn at the bottom of the CGContext's destination surface, which with the status bar enabled is in the status bar and clipped out while we're drawing Web content. If I hide the status bar, I can see the bug with retained layers disabled (although I haven't verified it still occurs in a pre-retained-layers build).
OK, in my Firefox 3.6 build that I have lying around, if I disable the status bar I can see the bug!
I'm not sure what the best workaround is here.

We could clip to the widget overflow area around HIThemeDrawFrame. That would stop garbage randomly outside the themed element, but as the testcase shows, we can still show garbage within the element.

I thought fiddling with HIThemeOrientation might change things; it does, but only makes the bug appear in a different way (the length of the horizontal line is equal to the height of the element that is showing).

Passing kHIThemeFrameTextFieldSquare as the kind seems to have no problems. Can we do that? It's not visually identical to kHIThemeFrameListBox :-(.

We could draw the listbox frame by hand. That doesn't look hard.

Josh, Markus --- any suggestions?
I don't see this, or I don't know what to look for. Can you attach a screenshot of the testcase?
Also, are you on 10.5 or 10.6?

Drawing the listbox frame by hand seems like the simplest solution to me. I might even have a patch for it lying around somewhere because at some point I was annoyed by the wrong colors - -moz-appearance:listbox is used by XUL trees, and native trees use slightly different border colors.
Attached image FF3.6 screenshot
Note the horizontal black line at the left side of the bottom edge of the window. The listbox scrollbar overlaps it.

This is on 10.5.

I'd love to see a patch for Gecko drawing of the listbox frame. It looks pretty simple to me.
OK, I definitely don't see this on 10.6.
Patch coming up.
Attached patch patchSplinter Review
Assignee: roc → mstange
Attachment #461642 - Flags: review?(joshmoz)
Attachment #461642 - Flags: review?(joshmoz) → review+
Attachment #461642 - Flags: approval2.0?
Attachment #461642 - Flags: approval2.0? → approval2.0+
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b3
blocking2.0: ? → betaN+
You need to log in before you can comment on or make changes to this bug.