521746 - table borders do not display with Ubuntu Karmic's Intel driver (probably bug in X driver)

Status: RESOLVED WORKSFORME

(Core :: Layout: Tables, defect)

Description

[Micah Gersten]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2b1pre) Gecko/20091010 Ubuntu/9.10 (karmic) Namoroka/3.6b1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2b1pre) Gecko/20091010 Ubuntu/9.10 (karmic) Namoroka/3.6b1pre

This seems to work in Konqueror, Arora, and Epiphany.
This does not work in Firefox 3.0, 3.5, 3.6preb1, 3.7prea1

Reproducible: Always

Actual Results:  
Borders do not render in test case

Expected Results:  
Borders should render in test case

Comment 1

[Micah Gersten]

Attachment: Borders do not render (test case)

I forgot, this was from Launchpad:
https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/448686

Comment 2

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2b1pre) Gecko/20091009 Namoroka/3.6b1pre

This works fine for me on Windows. Does it also fail with the latest official nightly? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

Comment 3

[Daniel Holbert [:dholbert]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091011 Minefield/3.7a1pre

Works fine for me, using Ubuntu Karmic on an x86 box... Maybe this is 64-bit-dependent for some reason? (comment 0 includes a 64-bit user agent)

Micah: Can you attach a screenshot of how the testcase renders?
(Alt + PrintScreen will snapshot the currently-focused window, in Ubuntu)

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to comment #3)
> Maybe this is
> 64-bit-dependent for some reason? (comment 0 includes a 64-bit user agent)

Nevermind -- this can't 64-bit dependent, because the launchpad bug was filed by someone on an i386 box.

Comment 5

[nandhp]

Yes, I (the original reporter) use x86. I am attaching a screenshot.

Comment 6

[nandhp]

Attachment: Testcase Screenshot

Comment 7

[Daniel Holbert [:dholbert]]

nandhp: I see from the launchpad bug that you still see this issue on a clean profile.  (And I've just confirmed that I *don't* see the issue, even with a clean profile.)

So, we need to narrow down what's different about our Karmic boxes that's causing the problem on your system but not on mine.

Could you try the following:
 (a) switch to Ubuntu's default Gnome theme ("Human"), reboot (to make sure all old-theme stuff gets cleared), and then see if you can reproduce?
 (b) boot from the official Karmic Beta LiveCD[1], and see if you can reproduce this in the LiveCD environment?

[1] http://releases.ubuntu.com/releases/9.10/ubuntu-9.10-beta-alternate-i386.iso

Comment 8

[Micah Gersten]

Confirmed on Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091011 Minefield/3.7a1pre

I have an Intel graphics chipset based on the 965 chipset. if that makes a difference.  I have not had a chance to confirm on live CD yet.

Comment 9

[nandhp]

I have not yet been able to reproduce the problem on a Live CD. However, I have only been able to test the Live CD in VMware, since I don't have any blank CDs available at the moment and I can't figure out how to boot the Live image using my hard disk. I'll keep trying to figure that out.

I have been able to reproduce the problem in both my user session with the default theme (after a reboot) and in a fresh guest session. On a whim, I tried some older versions of Firefox, and found that the problem also occurs in Firefox 3.0.14 (But not in 2.0.20) and in Seamonkey 2.0RC1. I proceeded to examine nightly trunk builds of Firefox until I found this pair:

2007-02-23-04-trunk works, 2007-02-24-04-trunk does not.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/02/2007-02-23-04-trunk/
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/02/2007-02-24-04-trunk/

I checked here for the changes:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&branch=HEAD&date=explicit&mindate=2007-02-23+04:00&maxdate=2007-02-24+04:00

and found that there was at least one change to the behavior of beveled collapsed borders, bug #371182. The test case for #371182 shows a solid black border with faint diagonal lines at the corners (as described by the reporter of 371182) in 2007-02-23-04-trunk, but no border at all in 2007-02-24-04-trunk (as described in this bug).

I have no idea if this information is useful, but I'll keep trying to reproduce the problem on a Live CD.

Here is the complete list of User-Agents I tested:

NO PROBLEM:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20070101 Minefield/3.0a2pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20070201 Minefield/3.0a2pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070220 Minefield/3.0a3pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070222 Minefield/3.0a3pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070223 Minefield/3.0a3pre
PROBLEM:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.14) Gecko/2009082707 Firefox/3.0.14
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4) Gecko/20091007 SeaMonkey/2.0
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008010104 Minefield/3.0b3pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a5pre) Gecko/20070601 Minefield/3.0a5pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070301 Minefield/3.0a3pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070225 Minefield/3.0a3pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070224 Minefield/3.0a3pre

Comment 10

[nandhp]

I cannot reproduce the problem using

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090924 Ubuntu/9.10 (karmic) Firefox/3.5.3

on the Karmic Live CD on my actual computer.

My graphics card is also Intel, but an i915, not a 965. Here's my lspci -vnn:

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
	Subsystem: Lenovo Device [17aa:20e4]
	Flags: bus master, fast devsel, latency 0, IRQ 30
	Memory at f4400000 (64-bit, non-prefetchable) [size=4M]
	Memory at d0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 1800 [size=8]
	Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
	Capabilities: [d0] Power Management version 3
	Kernel driver in use: i915
	Kernel modules: i915

00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07)
	Subsystem: Lenovo Device [17aa:20e4]
	Flags: bus master, fast devsel, latency 0
	Memory at f4200000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: [d0] Power Management version 3

At this point, the only odd thing I can think of about my system is that I had been running Shiretoko (Firefox) 3.5 on Jaunty using packages from the Ubuntu Mozilla Security PPA:
https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa
So there might have been some kind of error in the upgrade to Karmic (I did not have the problem in Jaunty). However, I did try reinstalling the Firefox packages, and that didn't fix the problem.

Comment 11

[Daniel Holbert [:dholbert]]

Thanks for the regression-range in comment 9 -- that's super-helpful.

So, bug 371182 modified Cairo-specific code.  It's possible that the root cause here is that your system's "libcairo2" version is buggy, if your broken Firefox versions are built with "--enable-system-cairo." (Though I'm not 100% sure whether "enable-system-cairo" refers to the system version at build-time or run-time.)

Just to test this theory -- what version of libcairo2 do you have? (apt-cache show libcairo2 | grep Version )  I have Version 1.8.8-2ubuntu1.

Comment 12

[Daniel Holbert [:dholbert]]

Have you tested the latest official nightly, too?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009-10-13-03-mozilla-central/

If the --enable-system-cairo theory in comment 11 is correct, I predict that the latest mozilla-central version should *not* be broken for you, because it doesn't use  --enable-system-cairo.

(mozilla-central nightlies haven't used --enable-system-cairo for some time now, though it's possible that the older versions (i.e. the ones you tested) did.  You can check a particular version's build configuration by visiting "about:buildconfig" in the build.)

Comment 13

[nandhp]

I have the same version of libcairo2: 1.8.8-2ubuntu1. Reinstalling cairo did not help. Downgrading cairo to the version in Jaunty did not seem to help either. The Ubuntu version's buildconfig does include "--enable-system-cairo".

The mozilla-central nightly you linked to unfortunately *does* exhibit the problem, even though it does not have "--enable-system-cairo". The builds I tested did not have "--enable-system-cairo" either -- or at least not the ones from the 23rd and 24th.

Comment 14

[nandhp]

It just occurred to me try running Firefox on my computer using a remote X display on another computer (running Ubuntu Hardy). This does *not* exhibit the problem. I also tried the reverse, running the Ubuntu Hardy Firefox on my X display, and this does have the problem.

Comment 15

[Nicolas Briche]

I upgraded my main computer to Karmic today, and I'm affected (Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.3) Gecko/20091020 Ubuntu/9.10 (karmic) Firefox/3.5.3).  I tried and also failed with the current official release, with a fresh profile, and all plugins and add-ons disabled.

No problem however, on a pre-release VirtualBox Karmic with libcairo2 1.8.8-2ubuntu1 (Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.3) Gecko/20091007 Ubuntu/9.10 (karmic) Firefox/3.5.3), running on the same computer.

My computer uses an Intel chip (82G33/G31 Express Integrated).

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Does this happen using only the Ubuntu builds, or does it also happen using a build you download from https://www.mozilla.com/ ?

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Er, sorry, comment 13 seems to answer that, although it would be good to know that other people observe the same thing.

Comment 18

[Nicolas Briche]

(In reply to comment #17)
> Er, sorry, comment 13 seems to answer that, although it would be good to know
> that other people observe the same thing.

Sorry, by "current official release", I meant FF 3.5.4 available from mozilla.org as of today (Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4).

I just tried on my eeepc 901, also running an up-to-date Karmic, Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.3) Gecko/20091020 Ubuntu/9.10 (karmic) Firefox/3.5.3.  It also shows the problem.

Does anyone _not_ using an intel X driver shows the problem?

Comment 19

[Nicolas Briche]

The latest Karmic build still show the problem on eeepc901.

Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.4) Gecko/20091028 Ubuntu/9.10 (karmic) Firefox/3.5.4

I'm preparing a karmic livecd that I'll test on an NVidia-based box and on the eeepc.

Comment 20

[Nicolas Briche]

Well, with a livecd on the same eeepc901, vesa X driver, the bug doesn't show.

LiveCD's user agent is Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.3) Gecko/20091020 Ubuntu/9.10 (karmic) Firefox/3.5.3, same as my comment #18.

It seems to be a bug specific to intel X drivers, limited to table borders.

I wonder if other elements redefined as tables by CSS properties are also affected?

Comment 21

[Daniel Holbert [:dholbert]]

(In reply to comment #20)
> Well, with a livecd on the same eeepc901, vesa X driver, the bug doesn't show.
[SNIP] 
> It seems to be a bug specific to intel X drivers, limited to table borders.

Interesting.  This would explain comment 14 as well -- presumably the remote (working) X display from that comment was using non-Intel drivers, and so it didn't hit the bug.

> I wonder if other elements redefined as tables by CSS properties are also
> affected?

Yeah, they should be.  In fact, a <table> element is essentially just implemented as a generic element "redefined as tables by CSS properties" -- see 
http://mxr.mozilla.org/mozilla-central/source/layout/style/html.css#180

Comment 22

[Nicolas Briche]

(In reply to comment #21)

> > I wonder if other elements redefined as tables by CSS properties are also
> > affected?
> 
> Yeah, they should be.  In fact, a <table> element is essentially just
> implemented as a generic element "redefined as tables by CSS properties" -- see 
> http://mxr.mozilla.org/mozilla-central/source/layout/style/html.css#180

We may be back to the border-collapse trail mentioned in comment #9, then.  I only found this bug because I've just been hit by it, and my "border: 2px solid black" tables were suddenly borderless.  But only the tables; I've got plenty of other "border: 2px solid #xxx" elements with correct rendering (mostly div and p).  The only difference I can see between those elements is the border-collapse.  Just now, using Firebug to disable only this property, the borders came back.

Comment 23

[nandhp]

Actually the remote machine from comment #14 _does_ have Intel graphics:

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c) (prog-if 00 [VGA controller])
        Subsystem: Dell Unknown device [1028:0275]
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at f8000000 (64-bit, non-prefetchable) [size=1M]
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at 1800 [size=8]
        Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
        Capabilities: [d0] Power Management version 3

00:02.1 Display controller [0380]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a03] (rev 0c)
        Subsystem: Dell Unknown device [1028:0275]
        Flags: bus master, fast devsel, latency 0
        Memory at f8100000 (64-bit, non-prefetchable) [size=1M]
        Capabilities: [d0] Power Management version 3

But it runs Ubuntu Hardy, and this problem only started appearing with Ubuntu Karmic (at least for me). It should be noted that there were several changes to the Intel graphics support in Karmic, e.g. from the release notes:

The Intel video driver has switched from the "EXA" acceleration method to the new "UXA", solving major performance problems of Ubuntu 9.04. Ubuntu 9.10 Beta also features kernel mode setting by default on Intel hardware, which reduces boot-time flickering and dramatically speeds up suspend/resume.
( http://www.ubuntu.com/testing/karmic/beta )

Comment 24

[Flemming Frandsen]

I have an additional data point, the same version of Firefox (Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4) Gecko/20091028 Ubuntu/9.10 (karmic) Firefox/3.5.4) that fails for me on 2 different Intel chipsets works fine with nvidia.

Comment 25

[Nicolas Briche]

That would tend to confirm nandhp's comment about UXA, then.  Is there anything about border-collapse's implementation that would trigger a reaction specifically with UXA?

Comment 26

[nandhp]

I'm pretty sure now that this relates to the Intel driver. I tried adding 'Driver "vesa"' to my xorg.conf:

 Section "Device"
 	Identifier	"Configured Video Device"
+	Driver		"vesa"
 EndSection

and restarting X. This fixes the problem, although I'm not sure how to confirm that I'm really using VESA (Xv video overlay is unavailable, so I guess that's a good sign).

Comment 27

[Nicolas Briche]

(In reply to comment #26)

> and restarting X. This fixes the problem, although I'm not sure how to confirm
> that I'm really using VESA

Checking /var/log/Xorg.0.log, you should find a bunch of lines beginning with

(II) VESA(0):

Basically the bottom half (or more) of the file should begin with this.  IIRC.

Comment 28

[nandhp]

(In reply to comment #27)
> Checking /var/log/Xorg.0.log, you should find a bunch of lines beginning with
> 
> (II) VESA(0):
> 
> Basically the bottom half (or more) of the file should begin with this.  IIRC.

It does -- it is the only recent Xorg log file to mention VESA at all.

Comment 29

[Nicolas Briche]

Okay, new weirdness:

With a table long enough (5 pg-down worth in my case), scrolling makes the _right_ border re-appear as the table scrolls down.  Scrolling up again makes it appear too.  That was in my intranet, with a 2-col layout, table on the right.

So I modified the test case, by copy/pasting about 200 more <tr/> for each table.  Now it's the _left_ side that reappears while scrolling.  It's sporadic, though: depending on whether you drag the scrollbar or use the mousewhell, or even how fast you go, it may leave 'holes'.

I'm using Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.4) Gecko/20091028 Ubuntu/9.10 (karmic) Firefox/3.5.4.

Comment 30

[Nicolas Briche]

Attachment: Test case, long tables

Scroll up and down, see if any border re-appears.

Comment 31

[Nicolas Briche]

Oh, and no screenshot of the re-appeared border, because trying to do so makes them disappear again.

Comment 32

[nandhp]

Attachment: Screenshot of reappeared borders from scrolling

I am attaching a screenshot showing the reappearing of the borders when scrolling.

Comment 33

[Bernd]

Could you please retry with a nightly that incorporates http://hg.mozilla.org/mozilla-central/rev/91e00d39570f it fixed a couple of invalidation issues for border collapse borders.

Comment 34

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This seems unlikely to be a layout bug, I think.

Comment 35

[Flemming Frandsen]

New data point: I've just reproduced the problem with an older 32 bit firefox I had around from when flash didn't exist in a 64 version:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.9) Gecko/2009040820 Firefox/3.0.9

This version worked fine before upgrading, so there is little doubt that this is a karmic bug rather than a Firefox bug.

Comment 36

[nandhp]

I just thought I'd mention that I saw on the Burning Edge that bug #452319 (border-collapse rewrite) was fixed, so I tried the nightly https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/11/2009-11-21-03-mozilla-central/ , but there was no change.

Comment 37

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So the functions that are specific to drawing table borders are nsCSSRendering::DrawTableBorderSegment and DrawSolidBorderSegment in nsCSSRendering.cpp.  In particular, if you look at DrawSolidBorderSegment:

http://hg.mozilla.org/mozilla-central/file/bcb580c05f4c/layout/base/nsCSSRendering.cpp#l2829

I think (based on reading the code):
 * the DrawLine case never gets hit (because the code is clearly broken, and
   because it should have been checking == aTwipsPerPixel rather than ==1)
 * the FillRect case is the reason that the borders are still being drawn
   correctly when they're one pixel wide
 * the FillPolygon case is what's broken
but it would be nice to confirm this.

Then the next step would be coming up with a simpler testcase (on top of the X APIs directly, or if that's too hard, at least on top of just cairo) that exhibits the same bug on this driver.

Comment 38

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So there only seem to be two uses of FillPolygon in our code.  This table border drawing code is one of them.  The other one of them is checkmark drawing for non-themed checkboxes, i.e., the check mark in:

data:text/html,<input type='checkbox' checked style='-moz-appearance:none'>

However, that seems to work ok.  So it seems like some FillPolygon calls work and some don't.

Comment 39

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The difference between the two FillPolygon calls is the AntialiasMode of the context; if I comment out this line:
  ctx->SetAntialiasMode(gfxContext::MODE_ALIASED);
in nsCSSRendering::DrawTableBorderSegment, then the borders start appearing again (though with seams, which is what that call is designed to prevent).

Comment 40

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: simple testcase program on top of Gtk/Gdk/cairo

Here's a simple testcase program that shows the problem, written on top of Gtk+Gdk+cairo.  I haven't looked into what X calls cairo is making (it might just be XFillPolygon, though I don't know how the antialias mode translates).

This draws a triangle on an Xvnc server, but draws nothing on the Intel server.

Comment 41

[Nicolas Briche]

This bug seems to have been resolved with the latest libcairo2 (1.8.8-2ubuntu1.1) and/or xserver-xorg-video-intel (2:2.9.0-1ubuntu2.1) packages.  Could somebody confirm?

The xserver-xorg-video-intel changelog shows:

  * Add 101_uxa_free_scratchpixmapheader.patch. Fixes a problem with
    non anti-aliased cairo shapes not being rendered at all on intel
    graphics. Cherrypick from upstream 2.9.1 release. (LP: #458545)

which matches with David's findings.

Comment 42

[Nicolas Briche]

Can we close this bug?  Unless someone else still sees the problem, it's been resolved by xorg.

Comment 43

[Micah Gersten]

I'm running Lucid now and this seems to be fixed with the Intel driver updates.