191875 - Print preview scrollbars are missing/busted

Status: RESOLVED DUPLICATE of bug 191938

(Core :: Print Preview, defect)

Description

[Andreas Kunz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030202
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030202

In both Classic and Modern the print preview scrollbars are not painted
correctly. They still work, though, if you can guess where their elements are.

This regressed between 2003012908 and 2003020204. (both with the same fresh profile)
Bug 191574 was fixed during that time and was about print preview, but I don't
think it looks like the cause...

On IRC I was told this also is busted on Linux in Phoenix "since two days",
biesi did not see it on Linux in a Mozilla CVS build - but I don't know the
exact date of it. So I'm not sure if it is all/all...

Reproducible: Always

Steps to Reproduce:
1. Load a page (long enough to require a scrollbar in print preview, mozilla.org
should suffice)
2. Go to "File - Print Preview"

Actual Results:  
Scrollbar(s) is/are painted black in classic, in modern their border is painted
correctly, but the interior is gray.

Expected Results:  
Scrollbars should look like scrollbars.

I hope the component is correct. It's frontend stuff, but AFAIK it's only broken
in print preview, so...

Comment 1

[Andreas Kunz]

Attachment: Screenshot Modern+Classic

Screenshot

Comment 2

[José Jeria]

Also textareas get a black background color and dropdowns are not visible...
Looks pretty broken

Comment 3

[Andreas Kunz]

Can somebody try this with builds between 2003012908 and 2003020204?
Unfortunately there is no Windows build in this timeframe...
So that also might confirm the bug on other platforms.
Does this happen on todays Linux builds?

What José found made me think this should maybe block 1.3b.

Is the printed page also affected or only the preview?
I don't have a printer right now...

cc'ing biesi: please tell the date of your CVS build where you could not
reproduce this. Thanks!

Comment 4

[José Jeria]

Attachment: Screenshot showing dropdowns, textarea and scrollbars messed up

Comment 5

[Paul Wyskoczka]

Nominating for Buffy, nsbeta1

Comment 6

[Andreas Kunz]

Nominating as 1.3b blocker:
very recent (3-4 days) regression that makes print preview (and maybe printing)
quite ugly. I don't think you want to give people a Mozilla like this.

Comment 7

[Roland Mainz]

I am seeing the same issue in 2003-02-03-08-trunk Solaris2.7/SPARC nightly
build.

Comment 8

[Simon Montagu :smontagu]

Bug 191574 is totally the cause of this, and backing it out fixes the scrollbar
appearance.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Ugh. Some XUL frames use PaintSelf....  Proposed fix coming up.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: This fixes most of it

That fixes scrollbars, textareas, dropdowns.  It does _not_ fix <select
size="n"> for n > 1.

Comment 11

[Boris Zbarsky [:bzbarsky]]

roc, any ideas as to what's up with the listbox?  It's just painting garbage
here.  If I make the block inside paint its background (which looks like it
should be transparent, btw) then things are fine.   In the case when the block
is not painting, nothing really paints a background in that rect (the
scrollframe does not, and the nsFrame method that gets called does not paint a
background either).

Shouldn't the view just fall back on being transparent in that case instead of
showing garbage as the background?

Comment 12

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

Maybe views are being treated as opaque that are no longer opaque because the
use of the print setting is preventing the background from being painted?

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yeah. If a frame decides not to honour it's 'background-color' setting, it MUST
return PR_FALSE from CanPaintBackground.

This may mean you have to pass a prescontext into CanPaintBackground to give you
enough info to make the decision. That would be a fine change IMHO.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Attachment: yeah, this works....

OK, this does fix the most serious problems, but I do not like it one bit. 
With this change, markup like:

<div style="position:absolute; top:0">
aaaaaaaaaaaa
</div>
<div style="position:absolute; top:0; background: red">
bbbbbbb
</div>

paints in an undesirable way.  In the current code, the background will _not_
be painted, but the "aaaaaa" under the "bbbbbbb" will also not be visible.... 
With this patch both sets of text are painted, naturally.  I've filed bug
191938 on that....

Comment 15

[José Jeria]

Also elements with position fixed have black background, see Viewer Demos #12 in
Print Preview

Comment 16

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 113545 [details] [diff] [review]
yeah, this works....

Yeah, the patch fixes that.

Comment 17

[Andreas Kunz]

Robert O'Callahan, can you do the review?

I'm really sorry for bugging you in such an inappropriate way, but I think this
is important for 1.3b if you don't want to ship a print preview that never works
right on any platform. 
Drivers have still not decided if it is blocking or not, so I just want to
prevent that this is forgotten about...
Thanks...

Comment 18

[Boris Zbarsky [:bzbarsky]]

"never works right"?

This is only a problem if background printing is turned off.  (Granted, that is
the default setting.)

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think a better fix for this is to use the approach in bug 191938.

Comment 20

[Andreas Kunz]

Re comment #18:
Sorry, bz, technically I was wrong. 
But with regards to the zintillions of 1.3b downloaders who rarely change any
defaults it is correct. 
And that counts when deciding if this bug should block 1.3b.

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 22

[Andreas Kunz]

Clearing 'blocking1.3b' request because bug is duped.

(The other bug is not mine and I'm not sure everybody considers the problem
important, so I leave re-requesting there to others...)

Comment 23

[Andreas Kunz]

bzbarsky: just in theory, would it have been a good idea to use this patch here
for the 1.3 release to just fix the visual problem (while the one in bug 191938
was the better one for the trunk in long-term) if someone had thought of it a
month (sic!) earlier?
Compared to the rewrite in the other bug the changes here are minor and look
quite unrisky to my untrained eye (for a fix that would have weeks to prove to
be good).

Comment 24

[Boris Zbarsky [:bzbarsky]]

See comment 14.

The simple fix for 1.3 would perhaps be a backout of bug 191574.  If someone
wants to pitch that to drivers, go for it.

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We could just use the patch I used. It has baked on the trunk for a while now.
And more dups are getting filed than I expected.

Comment 26

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Fix checked into 1.3 branch after drivers discussion.