User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6 Chimera seems to change the clipping region for the PDF Browser Plugin while it is still handling an event (mouse click into the scroll bar thumb that initiated a scroll). Reproducible: Always Steps to Reproduce: 1. Download and install the PDF Browser Plugin 2. Got to the page above or any other page that has an embedded PDF 3. Click into the plugins scroll bar and scroll the PDF Actual Results: The top of the scroll bar is clipped away Expected Results: Scroll bar should not be clipped. See the same page in Internet Explorer or Mozilla. I believe this is because Chimera is changing the clipping region during the scrolling. I can't change the clipping region for the scroll bar to draw, since the OS draws it automatically while the scroll bar control is tracked.

Confirmed using Chimera/2002111204 on 10.1.5.

Taking

The problem here is that we have a timer that sends null events to the plugin (since we have no main event loop in cocoa to do this). However, it messed with the QuickDraw port, and sent null events while you were tracking the scrollbar in the plugin (and thus down inside of a mouse event handler). I fixed it not to send events to the plugin reentrantly, which fixes the problem.

Verified in the 2002-11-26-04 NB under 10.2.2.

Fixed for a single PDF in a window. Thanks a lot! But it doesn't seem to work if there are multiple PDFs inside the same window. This can happen if there are multiple tabs open inside one window which each contains a PDF. For example go to this page http://developer.apple.com/techpubs/macosx/CoreTechnologies/AppleScriptStudio/index.html and select "Open Link in New Tab" on each PDF link on the site. The drawing while scrolling will be garbled again. I guess idling one plugin instance messes the port state for the other. Maybe after idling the plugin the port state should be reset to what it has been before, or the lock to not reenter a plugin should be per window, not per plugin instance? Can also happen if multiple PDF are embedded into a web page (see attachment). (fyi, PDF plugin needs to be updated to 0.3.2 or the scrollbar will not work on the additional plugin instances in one window)

Manfred what's the status of this bug, is it still around or have you fixed it in th mean time?

I didn't fix it. It's still there, but you need to update the example. The link to the left PDF is outdated. Timers fire while I track the mouse in which the port origin is set for other plug-in instances. That messes up drawing. I think Camino should set the port origin back to the original whenever it's done after changing the port origin. If I look at the nsChildView::StartDrawPlugin() and EndDrawPlugin() pair this is not the case (if that's relevant code, I can not tell).

Bug still exists. In 20040715 NB, entire region is moved instead of just top part of scroll bar. Attaching screenshot of behaviour. Should this be fixed for 0.9?

Verifying. Issue still exists when multiple PDFs open in tabs. Single PDF works though. Updating summary to reflect actual issue.

"Multiple PDFs open in tabs" is not a normal activity... I'm pushing this to 1.1.

(In reply to comment #11) > "Multiple PDFs open in tabs" is not a normal activity... I'm pushing this to > 1.1. This happens to me not only with multiple PDFs open, but with multiple plugins loaded it seems. For example a flash ad on slashdot in one tab leads to this behaviour in the single open pdf document.

(In reply to comment #12) > This happens to me not only with multiple PDFs open, but with multiple plugins > loaded it seems. > For example a flash ad on slashdot in one tab leads to this behaviour in the > single open pdf document. > This is a way I can reproduce it with the Dec 5 branch nightly resonably reliably: Load http://www.adobe.com/products/acrobat/pdfs/pdfaccess.pdf in the first tab in a new window Load http://www.macromedia.com/shockwave/welcome/ in a new tab. Switch to the pdf tab after it just finished loading. The pdf plugin should have lots of drawing issues by now when scrolling. Perhaps one has to switch among the tabs back and forth a bit more for it to work, though :-( Tested with new account and profile, as well as my old profile

(In reply to comment #13) > This is a way I can reproduce it with the Dec 5 branch nightly resonably > reliably: > Load http://www.adobe.com/products/acrobat/pdfs/pdfaccess.pdf in the first tab > in a new window > Load http://www.macromedia.com/shockwave/welcome/ in a new tab. Switch to the > pdf tab after it just finished loading. > The pdf plugin should have lots of drawing issues by now when scrolling. > Perhaps one has to switch among the tabs back and forth a bit more for it to > work, though :-( > Tested with new account and profile, as well as my old profile > WFM with Version 2005120804 (1.0b1+). The scrolling is a bit choppy, but I couldn't get a single drawing issue. Tested only with my used profile.

I'm still having redraw issues with the given example (PDF+Shockwave-Website). I'm using the build 2005122708 (marked with "(1.0+)" without a "b" - am I on the wrong branch?).

Does this happen on trunk? I don't have a PPC machine to test with anymore.

(In reply to comment #16) > Does this happen on trunk? I don't have a PPC machine to test with anymore. > Yes. I just tested it using the 2007091000 trunk build on 10.4.7 and PDF Brower Plugin v2.2.3 and it's still an issue.

If the issue here is the handling of the graphics port (comment 8), then this is a widget issue, so moving.

FWIW, this behavior persists with the new PDFBP 2.3.1 in Camino 2.0b3pre and Firefox 3.0.x, 3.5b4, and latest-mozilla-central on Intel. Firefox tends to redraw a bit better (i.e., it redraws again to correct the display slightly more often), but it exhibits the incorrect redrawing nonetheless.

Kindly note the screenshot I submitted for Bug 496342 was with *only* one PDF open in a window with multiple tabs that are *not* PDFs. This is a regression from comment #10, which says one PDF in a tab works with multiple tabs open.

(In reply to comment #21) > Kindly note the screenshot I submitted for Bug 496342 was with *only* one PDF > open in a window with multiple tabs that are *not* PDFs. See comment 12. It's very likely that there was Flash in one of the other tabs.