submit button in file:///home/.devkey.html looks weird, "stripey"

[skierpage]

In joyride.2230 and browse 93, the [Submit] button in the developer key form looks weird, it's got funny vertical stripes. If I don't import the stylesheet http://activation.laptop.org/media/css/base.css , then it looks OK. It's probably something to do with the input and submit styling and background images in https://activation.laptop.org/media/css/global.css

[kimquirk]

Not a blocker for 8.2

[cscott]

Briefly looked at this. Yes, that's ugly. The same style is used at https://activation.laptop.org and looks fine on Firefox-4.xo as well as Firefox on my laptop, but looks bad on the XO using Browse, so this definitely seems to be a Browse rendering bug.

[erikos]

Don't see the above when I have acceleration disabled.

in /etc/X11/xorg.conf use Option "NoAccel" "true" in the device section

[erikos]

(In #6133) Personally I think this is a blocker - but I leave it to others to bump it - other cases where we can see the issue are #7830 and #7493

[bernie]

#6133 and #7493 were closed as dupes of this bug.

Inheriting the "high" priority from #6133.

[bernie]

Jordan, this smells like a geode_drv bug (it disappears with NoAccel). Are you still the man for these things?

[bernie]

We see trash in eToys only under tooltips when they disappear. It only happens with -xshm enabled. Might be the same bug... Ties will attach a screenshot shortly.

[bernie]

It might be worth resyncing our X server with what's being shipped in latest F9 updates, in case the bug is not driver specific.

[ties]

check the little square that's out of sync in the icons at the top

[ties]

another etoys image: look for the square just of center; a remnant of a viewer

[bert]

The Etoys issue is different IMHO because it only gives artifacts right under the cursor (happens when rendering where the cursor is moving, see #7612).

[dsd]

I'm pretty sure that our X server is already synced with what Fedora are shipping, but I can't check right now as fedora cvs is down

[JordanCrouse]

This is probably the same mechanism that is broken in #7612. I realize that this might be a blocker, but I am not going to be able to get to it for a couple of weeks. I would encourage some new volunteers to start investigating - it never hurts to have more then one X driver go-to guy.

[garycmartin]

Just for reference, just closed my dup #8760 "Web form button graphic for requesting a developer key is corrupt " reported last week after all the chatter about G1G1v2 having keys/no keys/security/no security, etc. It has a screen shot of the rather stripy corrupt Submit Query button. Please feel free to reopen if this has some other root cause.

[JordanCrouse]

Okay, standard X debugging rules apply. Can somebody make me a pygtk script that just draws the button and nothing else?

[thomaswamm]

There are apparently many test cases or symptoms. Are they all caused by the same bug?

See attachment test.html in #6133 for a simple html file.

#8040 is supposedly a dup. I still see it in 8.2-767.

[thomaswamm]

Screenshot - symptom described in #8040.

[dsd]

I see these issues (with certain GTK+ themes) on Fedora-XO quite a lot. I think it's this bug: https://bugs.freedesktop.org/show_bug.cgi?id=15700 but I haven't tried the workarounds.

[erikos]

The 'Option "MigrationHeuristic" "greedy"' option did work for my testcases. This comment is interesting: https://bugs.freedesktop.org/show_bug.cgi?id=15700#c5

[thomaswamm]

I think I see this bug, or a similar bug, with Firefox-6 in build 8.2-767.

Go to the home page, and watch the Google search text entry box change appearance as you try different zooms using ctrl+ and ctrl-

At high zoom, scrolling left and right shows more errors in display rendering.

[thomaswamm]

I tried the fix mentioned above (added Option "MigrationHeuristic" "greedy" to xorg.conf device section) and the display rendering bugs in Browse-98 and Firefox-6 went away (testing build 8.2-767).

As a side effect (and I could be wrong about this) my XO seems a bit faster than before. Need to do some quantitative testing, but have no time right now.

Will there be any undesirable side-effects from the fix? I've fallen in love with it already.

I don't understand any of this, I'm just doing Monkey See Monkey Do, but the results seem good.

[thomaswamm]

see commented one-line addition to /etc/X11/xorg.conf that seems to fix #7830.

[garycmartin]

Yep, adding Option "MigrationHeuristic" "greedy" to xorg.conf "Device" section worked here too on a B4 XO running 8.2-767. The "Submit Query" button on the developer key request form is now a nice grey gradient.

[JordanCrouse]

The MigrationHeuristic "greedy" option is a reasonable workaround for 8.2. Hopefully we can have this fixed for real in the next version of the driver. Its up to the project managers to determine if the change the xorg.conf is 8.2 worthy or not.

[erikos]

I think it would be great to have.

[dsd]

My vote would be for no changes for 8.2.0. It's a minor bug which didn't annoy us enough to pay attention to this ticket until very recently, and changing these kinds of settings risks having other side effects. We don't even understand the actual problem.

I would say fix it for 8.2.1, hopefully with a code fix rather than a workaround which upstream suggests only makes the issue less common...

[erikos]

Well it annoyed me for quite some time: #6133 Already the google entry is wrong because of that. See as well #7493

I can not estimate what consequences the workaround has though. Definitely up to someone with knowledge in the area. But would be nice someone look into it in any case.

[thomaswamm]

I have used my XO for several hours since patching my xorg.conf file. No problems seen, and no re-occurence of display rendering bugs. I have done some timing tests with and without the patch, and see no performance change (contrary to my initial impression).

If the patch can't go into 8.2.0 then we need an easy way for irritated users to find the work-around and install it themselves at their own risk. A detailed release note perhaps.

[Rmyers]

I noticed that the drawing problem described in this bug doesn't occur in Firefox, so I came here to add a note, and saw that erikos had reported this earlier. I also saw the 'MigrationHeuristic' patch mentioned here and appplied it. This clears up the behavior.

So the question I have now, is why does Firefox work right and Browse requires this patch?

[marco]

Browse does not use mozilla native themes "emulation", while I guess firefox does. I suspect that's the reason. (We turn it off in Browse because the current gtk theme is sort of broken in web pages).

[thomaswamm]

Bug persists in candidate-801. The work-around one-line patch to xorg-conf (see above) still works for me. I propose that this work-around be put into 8.2.1. Any comments? It makes the Browse home page look better.

[bernie]

Has anyone tested it on F11-XO1?

[bernie]

Could #10076 be another instance of this bug?

[bernie]

For the record, putting

Option "MigrationHeuristic" "greedy"

in xorg.conf did fix buttons in GNOME on F11-XO1.

[bernie]

Added this work-around to olpc-utils 1.0.20 and rebuilt the RPM in F11.