56076 - Text hilighting displayed incorrectly in location bar, on Bugzilla page

Status: RESOLVED DUPLICATE of bug 50814

(Core :: XUL, defect, P3)

Description

[Scott Gifford (old account)]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-5.0 i686; en-US; m18) Gecko/20001010
BuildID:    200010102

In the location bar and on some Web pages, text hilighted with the mouse is not
displayed properly on my system.

In the location bar, the hilight isn't visible at all, although it works.

On affected Web pages, such as the Bugzilla main page, hilighting is visible
when the text of a link is hilighted, only because it changes from blue to black.

The location bar never works, but other pages seem to be affected
intermittently.  It always seems to happen on Web pages after hilighting text in
the Location bar.

Hilighted text on affected Web pages (but not the Location bar) is displayed
correctly when the window with the hilighted text is not the active window; it
reverts to incorrect display when the window is made active.

Tested on M17 and on 2000101021.
I'm using RedHat 6.2, GTK 1.2.8, and the GTKStep theme for GTK.

Reproducible: Always
Steps to Reproduce:
Hilight text in Location bar; it acts hilighted, but does not look like it.

After that, hilight regular text on a Web page, such as the main Bugzilla page
at http://bugzilla.mozilla.org/.  It will also behave correctly, but not display
correctly.

Actual Results:  Hilighted text is displayed incorrectly.

Expected Results:  Correct display of hilighted text.

Comment 1

[Asa Dotzler [:asa]]

updating component to Selection.

Comment 2

[Simon Fraser [no longer active]]

cc linux and focus folks. Does anyone else see this?

Comment 3

[Akkana Peck]

I don't see this.

This probably isn't a selection problem, incidentally; if the selection is right
but the highlighting isn't drawing, it might well be a widget look and feel
problem.

Try setting this pref in prefs.js:
user_pref("ui.textSelectBackground", "green");
and see if the urlbar selection shows up (should be green now).  If so, there's
some problem with the way the look and feel class is figuring out your default
select color.

Comment 4

[Scott Gifford (old account)]

[ I replied to the email, but it bounced, so I'll comment via the Web page too.]

OK, I see.  That made the problem go away for white backgrounds, but
now I have the same problem when I go to a page with a green
background (which is way better; green is a much less common
background color than white).

So this is really a bug and a feature request it looks like.

The bug is why did Mozilla decide that white was a reasonable
background color for me?  There was no ui.textSelectBackground setting
before in my prefs.js before I entered this one.  Where does the
default come from?

And the feature request is for Mozilla to be more clever about
dynamically detecting textSelectBackground.  If text is selected in an
area where textSelectBackground is the same, or very close to, the
background color, Mozilla should dynamically change
textSelectBackground for that one selection, handling the case where
different text in the same selection has different background colors
correctly.

I submitted this as an enhancement request, Bug #56314.  It's not a
big deal, but it would be nice to have.  If anybody's interested in
that aspect of the issue, go ahead and comment on the new bug.

Comment 5

[Akkana Peck]

No, no, of course white is not the default selection highlight color; blue is. 
My point was that by adding the pref, you're testing whether the drawing code is
working and the color selection code is buggy, as opposed to the drawing code or
selection code being buggy.  Now that we know that it's the color selection code
that's buggy, we know it's an xptoolkit bug in the nsLookAndFeel on your
platform.  But it doesn't happen on all linux boxes -- works fine on mine -- so
it's probably something to do with your windowmanager/environment.

I agree that Mozilla ought to be smarter about making the selection color
contrast with the background (for a while we used XOR, but we stopped using that
for some reason, which I think had to do with the fact that on busy image
backgrounds it was hard to tell when anything was selected).  So filing that new
bug was a good thing to do (though I suspect there's already a bug somewhere
covering it).

Reassigning bug to XP Toolkit.

Comment 6

[Scott Gifford (old account)]

Looking more closely at it, the incorrect hilighting color probably came from my
GTK theme, which displays text boxes with a dark grey background, and therefore
uses a white hilight color.

Maybe if the hilight color is taken from the environment like that, the
background color for the Location bar should also come from the environment;
that at least would have made the Location bar work OK.

Or maybe it doesn't make sense to get this setting from the environment at all,
since a Web page is likely to have a wider variety of backgrounds than a GTK widget.

Comment 7

[John Morrison]

Wasn't this in the right place already -- Selection/mjudge?

Comment 8

[Akkana Peck]

No, the problem is that the highlighting is there but it's the wrong color, and
that comes from the XPToolkit.  There's nothing wrong with the backend
selection.

Comment 9

[Peter Trudelle]

->pavlov, future

Comment 10

[Scott Gifford (old account)]

I've confirmed it's getting this from my GTK setup.  In my .gtkrc, when I have:

	bg[SELECTED]    = "#ffffff"

the highlighting works incorrectly (using a white background).

If I change that to

	bg[SELECTED]    = "#00ff00"

it uses a perfectly hideous shade of green.

This setting makes the assumption that the foreground color is going to also be
what is configured in the .gtkrc file (in this case, a medium gray color).
Since Web pages for the most part won't have that background color, this
assumption isn't correct, and it behaves improperly.

I would propose setting this to a sane default (such as blue) instead of taking
it from GTK's environment, along with other text-box related settings.  That
would just be a couple-line patch in mozilla/gfx/src/gtk/nsDeviceContextGTK.cpp,
lines 306-317.

With my particular setup, it was a horrible bug; selection was unusable, and I
had no idea why.  I think that avoiding the possibility of selection being
unusable is a reasonable tradeoff for not using GTK's default color scheme.

Comment 11

[Dave]

cc self

Comment 12

[Dave]

Confirming the fact that the white highlight color appears to come from the
.gtkrc file in my home directory. Changing the field (under the last xfce_*
section: 'style "xfce_7"'... neither of the other two instances of this field in
the .gtkrc file appear to affect highlighting color under mozilla) bg[SELECTED]
="#ffffff" to bg[SELECTED] ="#000000" makes highlighting color black instead of
white.

Curiously at work, where I'm not getting this problem, I don't appear to have a
.gtkrc file in my home directory... or anywhere else on my system for that matter.

Comment 13

[Stuart Parmenter]

this is the same as another bug i have.  I will find it in a minute

Comment 14

[Stuart Parmenter]

duplicate of bug 50814.

*** This bug has been marked as a duplicate of 50814 ***