416121 - [Linux-only] A block element is printed as a bitmap image if it has different values for border-*-color (text unselectable)

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P4)

Description

[Ilja Sekler]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008020711 Firefox/3.0b4pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008020711 Firefox/3.0b4pre

If a block element in a web page has a border and the value for border-left-color, border-top-color, border-right-color and border-bottom-color is not identical, the entire block element including the border itself, the text inside etc. gets printed using image fallbacks.

It doesn't matter, in which particular way the border properties are specified.

The bug doesn't happen on Windows. Linux-only.

Reproducible: Always

Steps to Reproduce:
1. Open the testcase and print it to a postscript file.
2. Convert the postscipt file to PDF with ps2pdf.
3. Open the PDF file with acroread or evince.
Actual Results:  
The first div gets printed as a raster image, text unselectable. The second div prints OK.

Expected Results:  
The first div is printed like the second one.

Upon the request in https://bugzilla.mozilla.org/show_bug.cgi?id=378307#c8

Tested on Ubuntu 7.10.

Comment 1

[Ilja Sekler]

Attachment: Testcase

Comment 2

[Ilja Sekler]

I hope that I haven't violated the etiquette intolerably...

Comment 3

[Carsten Book [:Tomcat]]

Attachment: output on fedora 8

hm works for me, this is the result i got on Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b3) Gecko/2008020513 Firefox/3.0b3

Comment 4

[Carsten Book [:Tomcat]]

oh okay confirmed when i look closer at the pdf with 800 % 

Comment 5

[Ilja Sekler]

The bug is still there after the landing of bug 416018.

As a result of this issue, printing http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-02-13+00%3A00%3A00&maxdate=2008-02-14+00%3A00%3A00&cvsroot=%2Fcvsroot file takes 13 minutes 44 seconds (Firefox is unresponsive during this time) on my system, the size of generated postscript file is 22,8 MB in comparison with 10 seconds and 1.8 MB if the default style of table borders has been overridden by

table, td, th { border: 1px solid gray !important; }

in userContent.css. In effect, the bug causes also denial of service for Linux users, request blocking1.9.

Comment 6

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

If this gets fixed inside cairo before 1.6, we'll end up with the fix; otherwise, I don't see us working on this before shipping.

Comment 7

[Daniel Holbert [:dholbert]]

See also bug 419917.

Comment 8

[Ilja Sekler]

Recent changes on the trunk have made the testcase and the main complaint in the summary of this bug obsolete. The image fallback areas are limited to the corners of the upper div in the testcase now, the text inside doesn't get lost (due to checkins in bug 424423 at a guess?).

It reduces the impact of the underlying problem significantly, but it would be great if a real fix would be possible on the way to cairo 1.8. Linux is the only platform still awaiting a solution.

Comment 9

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

(In reply to comment #8)
> It reduces the impact of the underlying problem significantly, but it would be
> great if a real fix would be possible on the way to cairo 1.8. Linux is the
> only platform still awaiting a solution.

It's essentially fixed -- the only place where fallback will happen is at the border corners, or for complex borders large border radii (e.g. a border that forms a circle).  This should probably be marked as fixed.

Comment 10

[Ilja Sekler]

(In reply to comment #9)

> the only place where fallback will happen is at the border corners, or for 
> complex borders large border radii (e.g. a border that forms a circle).

It is still a regression from Firefox 2 and looks ugly if printed to PDF.

The problem was also a platform parity issue as Firefox 3.0 for Mac or Windows did not need image fallbacks, but now Firefox 3.1a2pre (2008-07-30) on Windows leaves border corners of the upper div in the testcase completely blank if printed, so the platform parity is improving ;-)

> This should probably be marked as fixed.

Well, the wording of this bug leaves no other logical solution. On the other hand, it is obvious that the goal was to get rid of image fallbacks, not just to sweep them deeper under the carpet.

I suggest

1) resolving this bug as FIXED and

2) filing a new bug to track the remaining issues on the way to make image fallbacks completely unnecessary on Linux.

Comment 11

[Daniel Holbert [:dholbert]]

Just re-tested this using latest mozilla-central nightly -- this is now WORKSFORME.  (I printed to PDF, and both divs' text is selectable in the resulting file.)

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