559494 - Adobe PDF Plug-in does not redraw screen correctly after ATL-TAB (away and back).

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Rob]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.5pre) Gecko/20100414 Namoroka/3.6.5pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.5pre) Gecko/20100414 Namoroka/3.6.5pre (.NET CLR 3.5.30729)

Here is a file that demonstrates this Bug: 
http://cltc.ucdavis.edu/images/documents/guides_reports/2009_pier_classrooms_conference_rooms.pdf

Use ALT-TAB to switch to another Window (that overlaps the Namoroka Window)
then switch back. You'll find a black (or partially black) page and the
"Plug-in's Tool-bar" (not Namoroka's) is also ruined. 

More in "Actual Results" section.



Reproducible: Always

Steps to Reproduce:
1. Open WinXP Notepad or browse one or your OS's Directory and create a Window that would partially overlap your Namoroka Window.
2. Load http://cltc.ucdavis.edu/images/documents/guides_reports/2009_pier_classrooms_conference_rooms.pdf in Namoroka.
3. ATL-TAB to your other Window, then ALT-TAB back.

Actual Results:  
The overlapped portion of the Namoroka Window is not redraw and NONE of the Plug-in's Tool-bar is redrawn (whether overlapped or not).

Clicking within the 'page area' of the PDF file (assuming you don't click on a now invisible (blacked out) 'PDF Link') will restore the entire PDF's 'page area' but none of the Tool-bar.

Use the mouse to roll-over the Plug-in's Tool-bar to redraw the Tool-bar a little bit at a time (like a Paint Brush Tool).

This particular PDF has an 'Index Sidebar(?)' (on the left) that also need to be rolled over to restore it.



Expected Results:  
The entire overlapped portion (only) should be redrawn and the Tool-bar should not disappear.

I have not seen this before yesterday.

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

i can confirm this issue using
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.5pre) Gecko/20100415 Namoroka/3.6.5pre
with
dom.ipc.plugins.enabled;false (default).
it does not happen if you set dom.ipc.plugins.enabled;true (non-default on 1.9.2 branch).

on trunk using
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.3a5pre) Gecko/20100414 Firefox/3.7
it is okay with either dom.ipc.plugins.enabled;false or dom.ipc.plugins.enabled;true set.

nppdf32.dll Version 9.1.0.163 was used.

it also fails with a local copy of given PDF. so i tested against several other PDFs i have but cannot reproduce. there seems to be something special with given pdf.

Comment 2

[Rob]

I found an 'Official Plug-in Test Page' that demonstrates most of the problem (and is a tiny download): http://plugindoc.mozdev.org/testpages/pdf.html

Comment 3

[Rob]

Also try this:

1. Ensure that Namoroka does NOT have a pending Update (check in [H]elp).
2. Click on the 'Click to save this file to your computer or another location' Icon (the 3.5" Floppy Disk).
3. Save the file to a non-default Directory (on WinXP the default Directory is "My Documents", so choose somewhere else).
4. Close Namoroka.
5. Allow Namoroka to finish closing completely (a few seconds) and re-Open Namoroka.
6. _Attempt_ to save the file again (but do _not_ bother doing so), notice that the NEW default Directory is the same as what you chose previously.
7. Wait for Namoroka to get a Nightly Update.
8. _Attempt_ to save the file again (but do _not_ bother doing so), notice that the _CURRENT_ default Directory is now reset to the prior one (on WinXP it will be "My Documents").


Restarting Namoroka manually does NOT reset the Adobe Reader Plug-in.

Restarting Namoroka after an Update (of Namoroka, not the Plug-in) DOES reset the Adobe Reader Plug-in (and also any '"Right-Click" - "More Tools"' choices).

The Update of Namoroka ought not to trash the Plug-in's settings.

Comment 4

[Benjamin Smedberg]

I cannot reproduce with nppdf32.dll 9.3.2.163 on Win7.

Assuming you can reproduce this with a secure version of Acrobat (9.1.0.163 is hopelessly insecure), can I get a regression range on trunk nightlies (IPC preffed off)?

Comment 5

[Jan]

I have the same problem (applies to switching between tabs etc. too) with the Lorentz Beta:

Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.3pre) Gecko/20100405 Firefox/3.6.3plugin1 GTBDFff GTB7.0 (.NET CLR 3.5.30729)

Adobe plugin is 9.3.2.163 on WinXP Home SP3 current patch level.

I find it funny that my about:config (all entries shown when filtering for "ipc", I did not change any of those settings) reads:
dom.ipc.plugins.enabled = false
dom.ipc.plugins.enabled.npctrl.dll = true
dom.ipc.plugins.enabled.npqtplugin.dll = true
dom.ipc.plugins.enabled.npswf32.dll = true
dom.ipc.plugins.enabled.nptest.dll = true
dom.ipc.plugins.timeoutSecs = 10

so maybe the out-of-process thing is not even applied to adobe?

Comment 6

[Jim Mathies [:jimm]]

(In reply to comment #4)
> I cannot reproduce with nppdf32.dll 9.3.2.163 on Win7.
> 
> Assuming you can reproduce this with a secure version of Acrobat (9.1.0.163 is
> hopelessly insecure), can I get a regression range on trunk nightlies (IPC
> preffed off)?

The DWM on Vista and Win7 don't require the app repainting, so probably only reproducible on XP.

Comment 7

[Jim Mathies [:jimm]]

(In reply to comment #5)
> so maybe the out-of-process thing is not even applied to adobe?

Yes, for the Lorentz release we've only white listed a few plugins - flash, silverlight, and quicktime.

You can test though by adding a new enabled pref for nppdf32.dll.

Comment 8

[Jim Mathies [:jimm]]

confirmed, this is really bad.

Comment 9

[Jim Mathies [:jimm]]

Also present in 3.6.3. We need a regression range.

Comment 10

[Jim Mathies [:jimm]]

(In reply to comment #9)
> Also present in 3.6.3. We need a regression range.

Actually I take that back. Acrobat was busy downloading the ucdavis doc, which is large and on a slow connection. While downloading, redraw was broken in 3.6.3, but once the doc fully loaded rendering was working correctly. So I think this might be a bug in acrobat.

On 3.6.4 though we definitely have an invalidation problem.

Comment 11

[Jan]

(In reply to comment #7)
> You can test though by adding a new enabled pref for nppdf32.dll.

Its already broken without OOPP, so why break it more? ;-)

Comment 12

[Jim Mathies [:jimm]]

We missed a patch in our merge to 1.9.2 - 

https://bugzilla.mozilla.org/show_bug.cgi?id=542337

http://hg.mozilla.org/mozilla-central/rev/1bf47245fd09

Comment 13

[Rob]

(In reply to comment #8)
>> confirmed, this is really bad.

Thanks for taking this Jim.


When I filed this I set the "Importance" to "Major" but someone demoted it to "Normal". 

I am of the opinion that (at least on MS Windows) the ability to read PDFs is part of the Operating System (since Adobe Reader is included FREE in most Consumer Desktops), and recently Linux/(Open)Solaris is adopting this view; much as Microsoft would have us use Internet Explorer (and MS Word) as an integral part of the Operating System (though that is more for ease of obtaining Updates, running the Validation Tool, and dominating the Market ;) ).

It is a ripoff that clicking PDF links will open Internet Explorer (at least on my System).

---

I have updated to Tab Mix Plus 0.3.8.3pre.100412a and Adobe Reader 9.3.2(.163 ?) (updated yesterday, [Help][About Adobe Reader 9] says it is _just_ 9.3.2), so I am at the bleeding edge and still see this issue.


>> Actually I take that back. Acrobat was busy downloading the ucdavis doc, which is large and on ...

See comment 2 , try http://plugindoc.mozdev.org/testpages/pdf.html that is tiny.

---

Rambling:
It was a coincidence? that a few days ago "plugin-container.exe" appeared (and now when I "Update Restart" I must let my Firewall permit TWO programs instead of only "Firefox.exe (Namoroka). I wish "plugin-container.exe" was renamed "namoroka-plugin-container.exe" and Firefox's was called "firfox-plugin-container.exe".

It is weird? that if I start Firefox (not Namoroka) that it reads Tab Mix Plus's data that was stored for the last run of Namoroka and lets me restore the Tabs from a _different_ program.

BTW: I hope 559494#c3 is fixed too.


Thanks again for taking this,
Rob

Comment 14

[Jim Mathies [:jimm]]

(In reply to comment #13)
> It was a coincidence? that a few days ago "plugin-container.exe" appeared (and
> now when I "Update Restart" I must let my Firewall permit TWO programs instead
> of only "Firefox.exe (Namoroka). I wish "plugin-container.exe" was renamed
> "namoroka-plugin-container.exe" and Firefox's was called
> "firfox-plugin-container.exe".

Lots of discussion is going on about naming of the sub process exe. In time it will contain more than plugins, (jetpack extensions, tabs, etc..) so this will change. For oopp though and a minor release it's "plugin-container", which is probably better than what it started out as which was "mozilla-runtime".

> 
> It is weird? that if I start Firefox (not Namoroka) that it reads Tab Mix
> Plus's data that was stored for the last run of Namoroka and lets me restore
> the Tabs from a _different_ program.
> 
> BTW: I hope 559494#c3 is fixed too.

Maybe file a new bug on that and cc me? Some clarification on your STR would help, I wasn't sure how to reproduce.

Comment 15

[Jim Mathies [:jimm]]

Forgot to mention - the 3.6.4 beta was spun up today so this missing patch will not be in it. Expect a lot of resolved dupe posts here in the near future. :) The fix will definitely be in the final release.

Comment 16

[Rob]

A newly discovered problem that is difficult to reproduce (occurs ~ 25% of the
time) is that when you load a PDF (and DO NOT try to ALT-TAB away and back) the
"Page Number Box" is black. Everything else is OK (until you ALT-TAB away and
back). 

Clicking in the box will show which page you are on and make the box's
background white. Doing the ALT-TAB, away and back, will produce the above Bug
and mouseover will not restore the "Page Number Box" so you must guess where to
click.

Using "Duplicate Tab" (or opening a blank Tab and loading the Page by pasting
the URL) will open a copy which likely will be OK (as far as the "Page Number
Box" is concerned) _most_ of the time.

Hopefully fixing the original BR will fix this also.

Rob

---

I have:
"C:\Program Files\Namoroka\firefox.exe"        (I call this "Namoroka")
"C:\Program Files\Mozilla Firefox\firefox.exe" (I call this "Firefox")

---

>> Lots of discussion is going on about naming of the sub process ...

Try "Googling" for ["plugin container" Namoroka] the only (relevant) page I could find on the (entire) Internet was: 
http://playpcesor.blogspot.com/2010/04/firefox-364-beta-out-of-process-plugins.html (and it is in Chinese so some may need the Google Translator, which makes for interesting reading! ;) ).

Our Wiki, web pages, forums, etc. need to open up for the Robots, we have nothing to hide.

BTW: Is the correct spelling (according to Namoroka's Spell Check) for 
"plugin-container.exe" actually supposed to be "plug-in_container.exe"


>> STR ...
STR = "Short tandem repeat", "Stand to Reason", str(), ... - definition please.

Rob

Comment 17

[Benjamin Smedberg]

Jim, can you attach the correct branch change here so we can request review on it?

Comment 18

[Jim Mathies [:jimm]]

Attachment: import

Comment 21

[Jim Mathies [:jimm]]

Comment on attachment 439705 [details] [diff] [review]
import

undoing change, we still need patch approval.

Comment 22

[LegNeato]

Comment on attachment 439705 [details] [diff] [review]
import

a=LegNeato for 1.9.2.4

Comment 24

[Benjamin Smedberg]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/ebf4912923d3
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/20adfac971a2 (relbranch)

Comment 25

[Al Billings [:abillings - ex-MoCo]]

I can't reproduce the original problem with the original PDF with the beta 1 Firefox 3.6.4 build at all.

Comment 26

[Jim Mathies [:jimm]]

(In reply to comment #25)
> I can't reproduce the original problem with the original PDF with the beta 1
> Firefox 3.6.4 build at all.

On Windows XP? (Vista and win7 won't see this due to the DWM.)

Comment 27

[Al Billings [:abillings - ex-MoCo]]

Ah, I was on Windows 7 as my Windows XP box is a build machine and I didn't want to pollute it. I'll try in another VM.

Comment 29

[Al Billings [:abillings - ex-MoCo]]

Verified fixed in 1.9.2 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9.2.5pre) Gecko/20100423 Namoroka/3.6.5pre (.NET CLR 3.5.30729).

Comment 30

[Rob]

Reporter: Quick answer is 50% FIXED, IE: Not Fixed.

The http://plugindoc.mozdev.org/testpages/pdf.html links "works" (after 2 seconds of testing), the http://cltc.ucdavis.edu/images/documents/guides_reports/2009_pier_classrooms_conference_rooms.pdf link 'freezes the redraw'. Once it loads it is OK, before (and after) it loads everything else is OK.


ALT-TAB and back shows 'a cutout' of the other Window.

Another (incorrect) way to explain it is that we have the opposite problem, IE: 'it is not "black"'.

Rob

Comment 31

[Rob]

Confirmed, Not Fixed.


Loads fast, looks great (IE: Does not test all of the problem)
http://plugindoc.mozdev.org/testpages/pdf.html

Freezes the old Window's redraw until loaded
http://cltc.ucdavis.edu/images/documents/guides_reports/2009_pier_classrooms_conference_rooms.pdf

PDF Video seems great, it would be better if each Video cascaded but that is not this Bug
http://www.ipov.net/content/rich-media-pdf


Google for "Atlas.pdf":

During the slow load of the huge file it demonstrates the 'freezing redraw' well
http://www.unep.org/pdf/carbon_biodiversity.pdf

Loads fast, looks great, too quick to decide 
http://atlas.ch/atlas_brochures_pdf/brochure_american.pdf

Small file loads slow, seems OK
http://www.teleatlas.com/stellent/groups/public/documents/content/ta_ct016623.pdf


These die a horrible death - lots of great thing to test here
http://www.acrobatusers.com/gallery/3d

Rob

Comment 32

[Al Billings [:abillings - ex-MoCo]]

You need to say what build you are using, Rob.

Comment 33

[Rob]

(In reply to comment #32)
> You need to say what build you are using, Rob.

I'm using Nightly, thus it is what it is ... (I get it when someone/thing commits it).

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.5pre) Gecko/20100423 Namoroka/3.6.5pre (.NET CLR 3.5.30729)

Still broken at this particular moment.

Thanks,
Rob

Comment 34

[Rob]

(In reply to comment #32)
> You need to say what build you are using, Rob.

Applied newest Update, still broken with the "freezing redraw", assumed to be one step before 'the blackening stage'. There are also many other problems that are for a different BR. IE: If this was in a recent release it is too badly broken to have been a "Release" (or a "Beta Release").


Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.5pre) Gecko/20100424 Namoroka/3.6.5pre (.NET CLR 3.5.30729)

Rob

Comment 35

[Al Billings [:abillings - ex-MoCo]]

It looks fine when I test it. I'm not sure what you are seeing. The originally reported bug looks fixed. If you are seeing new issues or ones with different results, I would suggest opening more bugs.

Comment 36

[Rob]

(In reply to comment #15)
> Forgot to mention - the 3.6.4 beta was spun up today so this missing patch

It goes back a bit as "not so good" but not all the problems are this BR.


I reinstalled Acrobat Reader and tested it with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)

The "ALT-TAB and back" results in a 'choppy redraw' bottom to top, thus the "Page Area" gets redrawn, then the "Reader Toolbar", then (in my particular case) the three rows of Tab Mix+ get rendered simultaneously then, finally, the "Firefox (NOT Namoroka for _this_ particular post) Toolbar; the MSW Frames are always present, (and I have fast eyes, with a slow Graphics Card).

Rob

Comment 37

[Jim Mathies [:jimm]]

(In reply to comment #35)
> It looks fine when I test it. I'm not sure what you are seeing. The originally
> reported bug looks fixed. If you are seeing new issues or ones with different
> results, I would suggest opening more bugs.

I experienced the lack of redraw during load as well. The black areas that
don't get redrawn are in fact fixed. We should file a new bug on the
loading/redrawing problem, I'm not convinced that's our fault. I believe I was
able to reproduce that with oopp disabled.

Comment 38

[Rob]

(In reply to comment #37)
> (In reply to comment #35)
> > It looks fine when I test it. I'm not sure what you are seeing. The originally
> > reported bug looks fixed. If you are seeing new issues or ones with different
> > results, I would suggest opening more bugs.
> 
> I experienced the lack of redraw during load as well. The black areas that
> don't get redrawn are in fact fixed. We should file a new bug on the
> loading/redrawing problem, I'm not convinced that's our fault. I believe I was
> able to reproduce that with oopp disabled.

OK by me Jim.

I was concerned that the 'halt at black areas finished' subroutine had been replaced with a 'do not attempt to get that far, thus avoiding the issue' subroutine  ;)  (Joking, please).

You understand this better than I, please file away.

If you feel the exact issue is fixed then please close, and THANKS again,
Rob

Comment 39

[Jan]

Funny thing is, after ALT-TABbbing back to Firefox the PDF sometimes shows up correctly for a split second, and THEN goes to black. WinXP, 3.6.4 beta.

Comment 40

[Rob]

(In reply to comment #38)
> I experienced the lack of redraw during load as well. The black areas that
> don't get redrawn are in fact fixed. We should file a new bug

I am not a fan of the "This is FIXED Club".

I tried the slow one and the quick one a bit later, I'm getting the "redraw freeze" but it is a lot like a "gray replaced the black Background" effect; not so much "Fixed" as it is "different". 

The short URL's download is entirely blocked by the slow URL's download, I get a gray screen on this Platform, with the short PDF showing the _origonal_ _BR_, (but in gray) and the one from bavis is not being rendered the same as on WinXP (no left-side-bar but it did come up with the 'Comment / Notes Area' (one the bottom) open.

It is about as close as to being the same BR without actually being exactly the same.


I'm using the plug-in from Adobe Reader 9.3.2 (04-01-2010) on OpenSolaris:

$ uname -a
SunOS opensolaris 5.11 snv_134 i86pc i386 i86pc Solaris


Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.3a4) Gecko/20100409 MozillaDeveloperPreview/3.7a4


Thanks for the efforts thus far,
Rob

Comment 41

[Jim Mathies [:jimm]]

(In reply to comment #40)
> (In reply to comment #38)
> > I experienced the lack of redraw during load as well. The black areas that
> > don't get redrawn are in fact fixed. We should file a new bug
> 
> I am not a fan of the "This is FIXED Club".
> 
> I tried the slow one and the quick one a bit later, I'm getting the "redraw
> freeze" but it is a lot like a "gray replaced the black Background" effect; not
> so much "Fixed" as it is "different". 
> 
> The short URL's download is entirely blocked by the slow URL's download, I get
> a gray screen on this Platform, with the short PDF showing the _origonal_ _BR_,
> (but in gray) and the one from bavis is not being rendered the same as on WinXP
> (no left-side-bar but it did come up with the 'Comment / Notes Area' (one the
> bottom) open.
> 
> It is about as close as to being the same BR without actually being exactly the
> same.
> 
> 
> I'm using the plug-in from Adobe Reader 9.3.2 (04-01-2010) on OpenSolaris:
> 
> $ uname -a
> SunOS opensolaris 5.11 snv_134 i86pc i386 i86pc Solaris
> 
> 
> Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.3a4) Gecko/20100409
> MozillaDeveloperPreview/3.7a4
> 
> 
> Thanks for the efforts thus far,
> Rob

Do you see similar issues with oopp disabled, or is this oopp specific?

Comment 42

[Mitch 74]

I can confirm this bug on 32-bit VistaSP2+platform update (the stuff needed to test IE 9) in VirtualBox with:
 - latest Adobe Reader 9.3.2 (+ build number)
 - Namoroka 3.6.4b1

I'll add the following symptoms:
 - Alt+tab isn't the only trigger for the bug: Ctrl+tab also does it
 - going back to the page with the PDF, I can see it being drawn once, then blacked out as soon as the page is done loading.

Comment 43

[Al Billings [:abillings - ex-MoCo]]

Mitch, confirming in 3.6.4 b1 doesn't help. It wasn't fixed until AFTER beta 1 was created. If you look at the data in your build ID and look at comment 24, you can see that the date in your build ID is earlier than this.

Comment 44

[Mitch 74]

@Al: according to previous comments, the bug in 3.6b1 was limited to XP. Also, the original description only mentioned Alt+Tab switches.

Now testing latest Minefield 32-bit build on Win7, under VirtualBox. Cannot reproduce the bug. Bug is present in Lorentz beta 1 on the same system, though. I think this bug can be marked resolved, and fixed next time there's a Lorentz release...?

Comment 45

[Al Billings [:abillings - ex-MoCo]]

This will be fixed when Firefox 3.6.4 ships. It definitely reproduced in XP but it wasn't clear if it did in Windows 7. It was never ruled out.

I've resolved this as fixed since it is 1.9.2 only.

Comment 46

[Rob]

Reporter: Fixed. Thanks one and all, Rob.