360793 - Adjusting drag-selection leaves areas with wrong color

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Mats Palmgren (inactive)]

STEPS TO REPRODUCE
1. load URL
2. scroll down to #42
3. click-left-drag-select starting to the right of the text and drag
   slowly upwards up to to "41" then down again and move the mouse over
   the left edge of the link "www.alibaba.com" a few times (see screenshot)

ACTUAL RESULTS
Blocks of lighter blue color appears where there is no selection.
This is not the secondary selection color, which is grey.
It appears to be the same color as is blended for selected images.
I can reproduce the bug at the top of the page also, leaving some images
appearing to be selected when they are not.
Clicking on another window fixes it. Show/hide the context menu
on the page repairs the damage where the menu was located, mostly.

I can't reproduce the bug in a Firefox trunk debug build of the same date.

PLATFORM AND BUILD
Firefox debug build of REFLOW_20061031_BRANCH dated 2006-11-14 on
Linux/x86_64.

Comment 1

[Mats Palmgren (inactive)]

Attachment: Screenshot #1

The darker blue is the primary selection color.

Comment 2

[Mats Palmgren (inactive)]

It's a cairo-gtk2 build.

Comment 3

[Bill Gianopoulos [:WG9s]]

(In reply to comment #0)
> I can't reproduce the bug in a Firefox trunk debug build of the same date.

What do you mean by of the same date?

In order to determine if this is a reflow branch or a Cairo issue, you would really need to compare with a non-reflow Cairo build from 20061031.

Comment 4

[Mats Palmgren (inactive)]

I can reproduce the bug in Firefox nightly trunk 2006-10-31-04 and 
trunk 2006-11-25 (both cairo-gtk2 on Linux). The trunk debug build I tested
was a non-cairo build dated 2006-11-14. So this is a cairo regression
not a reflow-branch regression.

Comment 5

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I can't reproduce the specific issue on win32, but there's another thing here... the little 2x3 pixel bit in between each entry that shows up as a slightly lighter color is because there's a "shim" image there.  We draw images as selected by painting a partially transparent rectangle over them, and I'm not sure how selected text is being drawn -- but that's the difference between those two issues.

The problem that's being seen in the rest of the text is having it be drawn in the same color as that shim ends up being, which is a little odd, so there could be something related there.

Comment 6

[Mats Palmgren (inactive)]

I can't reproduce the problem at the URL anymore (possibly because the
content at the URL have changed), Firefox 20070321 Linux.
I think this might be the same problem as in bug 374765 (which has testcase
and patch).

Comment 7

[Mats Palmgren (inactive)]

''because there's a "shim" image there'' in comment 5 makes me think this
was the same issue as bug 374765.  Should be fixed now.

-> WORKSFORME