Ticket #7830 (closed defect: fixed)

Opened 6 years ago

Last modified 4 years ago

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

Reported by: skierpage Owned by: bernie
Priority: high Milestone: 8.2.1
Component: x window system Version: olpc-3
Keywords: 8.2.1? Cc: cscott, JordanCrouse, dgilmore, dsd, garycmartin, gregorio, Rmyers
Action Needed: diagnose Verified: no
Deployments affected: Blocked By: #6133
Blocking:

Description

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

Attachments

tmpsgM_Qv.png (49.4 kB) - added by ties 6 years ago.
check the little square that's out of sync in the icons at the top
tmpi9zJcZ.png (46.1 kB) - added by ties 6 years ago.
another etoys image: look for the square just of center; a remnant of a viewer
tmpZw9cWD.png (97.0 kB) - added by thomaswamm 6 years ago.
Screenshot - symptom described in #8040.
xorg.conf (2.5 kB) - added by thomaswamm 6 years ago.
see commented one-line addition to /etc/X11/xorg.conf that seems to fix #7830.

Change History

Changed 6 years ago by marco

  • next_action changed from never set to diagnose

Changed 6 years ago by kimquirk

  • cc cscott added
  • keywords polish:8.2.0 added

Not a blocker for 8.2

Changed 6 years ago by 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.

Changed 6 years ago by erikos

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

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

Changed 6 years ago by erikos

  • blockedby 6133 added

(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

Changed 6 years ago by bernie

  • priority changed from normal to high

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

Inheriting the "high" priority from #6133.

Changed 6 years ago by bernie

  • cc JordanCrouse added

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

Changed 6 years ago by 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.

Changed 6 years ago by bernie

  • cc dgilmore added

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.

Changed 6 years ago by erikos

  • keywords 8.2.0? added; polish:8.2.0 removed
  • owner changed from erikos to bernie
  • component changed from browse-activity to x window system

Changed 6 years ago by ties

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

Changed 6 years ago by ties

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

Changed 6 years ago by 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).

Changed 6 years ago by dsd

  • cc dsd added

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

Changed 6 years ago by 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.

Changed 6 years ago by garycmartin

  • cc garycmartin added

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.

Changed 6 years ago by JordanCrouse

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

Changed 6 years ago by 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.

Changed 6 years ago by thomaswamm

Screenshot - symptom described in #8040.

Changed 6 years ago by 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.

Changed 6 years ago by 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

Changed 6 years ago by 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.

Changed 6 years ago by 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.

Changed 6 years ago by thomaswamm

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

Changed 6 years ago by 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.

Changed 6 years ago by 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.

Changed 6 years ago by erikos

  • cc greporio added

I think it would be great to have.

Changed 6 years ago by dsd

  • cc gregorio added; greporio removed

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...

Changed 6 years ago by 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.

Changed 6 years ago by 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.

Changed 6 years ago by Rmyers

  • cc Rmyers added

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?

Changed 6 years ago by 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).

Changed 5 years ago by thomaswamm

  • keywords 8.2.1? added; 8.2.0? removed
  • milestone changed from 8.2.0 (was Update.2) to 8.2.1

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.

Changed 5 years ago by bernie

Has anyone tested it on F11-XO1?

Changed 4 years ago by bernie

Could #10076 be another instance of this bug?

Changed 4 years ago by bernie

For the record, putting

Option "MigrationHeuristic" "greedy"

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

Changed 4 years ago by bernie

  • status changed from new to closed
  • resolution set to fixed

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

Note: See TracTickets for help on using tickets.