124563 - Acrobat PDF plug-in fails to completely draw its' chrome on load in Mozilla

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P2)

Description

[Greg K.]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.8) Gecko/20020204
BuildID:    2002020405

The Acrobat PDF plug-in fails to completely draw its' own chrome when invoked in
Mozilla, leaving parts of the previous document visible.

Reproducible: Always
Steps to Reproduce:
1. Access a normal HTML document such as [http://www.mozilla.org]
2. Access a PDF document such as the example URL.

Actual Results:  The Acrobat Plug-in fails to completely draw its' chrome,
leaving parts of the previous document visible.

Expected Results:  The plug-in should have completely drawn its' chrome,
overwriting the old document.

If the Mozilla window is hidden, then redisplayed, the plug-in chrome is fully
displayed.

The plug-in works as expected in Mac IE 5.1.3 (4012).

Comment 1

[Greg K.]

Attachment: Screen shot of incompletely rendered plug-in chrome

Observe the incompletely rendered plug-in chrome in this screen shot.

1. Missing "Bookmarks" and "Thumbnails" tabs along the left side
2. Missing plug-in sidebar widget at bottom-left
3. Missing zoom percentage drop-down menu widget in toolbar
4. Incompletely drawn toolbar background at right, leaving previous black

Comment 2

[Greg K.]

Acrobat plug-in version used is that included with Acrobat Reader 5.0.5, a
Carbon application.

Comment 3

[Pete Boyd]

WFM [Mozilla 2002020803, Windows 2000, Acrobat reader 5.0.5]

it is a slow document to use tho, maybe its using up too much of your video RAM
(how much of that do you have?)

Comment 4

[shrirang khanzode]

I had seen this...does not happen when I have just ns6.x open. But with other 
apps running...this is seen. Part of the acrobat UI does not paint unless forced 
to redraw...true

Comment 5

[Peter Lubczynski]

-->peterl

Possibly related to bug 120168 

Comment 6

[scottputterman]

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 7

[shrirang khanzode]

nominating nsbeta1, thisis pretty bad

Comment 8

[Peter Lubczynski]

Attachment: patch to invalidate

Yeah, this is pretty bad. Here's a patch that seems to make it better.

Comment 9

[av (gone)]

Is this patch going to cause an additional 'flash' every time any full page
plugin is loaded?

Comment 10

[Peter Lubczynski]

have not yet tested on Windows or Linux. it's possible it needs some #ifdefs

Comment 11

[Peter Lubczynski]

Attachment: updated patch to exclude other platforms except for Mac

Mac is the only platform showing this problem because it does not have child
windows so this fix is Mac-only. This fix is not appropriate for other
platforms and may even cause a flicker.

Comment 12

[av (gone)]

Comment on attachment 75647 [details] [diff] [review]
updated patch to exclude other platforms except for Mac

r=av

Comment 13

[Winnie Lam]

adding adt2 to status whiteboard as per discussion with beppe.  this only
happens to mac users, although a patch is available already.

Comment 14

[Patrick C. Beard]

Comment on attachment 75647 [details] [diff] [review]
updated patch to exclude other platforms except for Mac

sr=beard

Comment 15

[Peter Lubczynski]

Comment on attachment 75647 [details] [diff] [review]
updated patch to exclude other platforms except for Mac

from comments

Comment 16

[Asa Dotzler [:asa]]

Comment on attachment 75647 [details] [diff] [review]
updated patch to exclude other platforms except for Mac

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 17

[Peter Lubczynski]

patch on trunk, marking FIXED.

Comment 18

[Greg K.]

I confirm this is resolved using Mac/2002032808.

Comment 19

[shrirang khanzode]

Thanks a lot, Greg! VERIFIED.