Community
Participate
Eclipse IDE
Build id: 200403250010 Chris, in defect 52723 you wrote: " for 3.0, the Browser widget is supporting the display of HTML documents. Other content (PDF, applets etc.) is not supported for 3.0. We are interested in fixing these post 3.0. so you should open a PR... " Im opening this PR for tracking. Here are the steps to see some problems with the SWT Browser widget: If you use the SWT browser to go to Eclipse.org and click on 1) (WARNING: this hangs UI) White Paper: the browser hangs the whole windows UI trying to handle the AdobeAcrobat plugin in IE. If you are patient enough, the UI will come back. 2) Eclipse Project FAQ. Nothing happens because this launches a new IE windows. And just as a side note, what is the official intention here behind the SWT Browser widget, is it a Browser widget? or is it an HTML widget? I believe the official intent should be documented. If only HTML support is expected, then it should be called HTML widget to emphasize the fact. You cant expect people to be careful with what page they point the browser to! no?
This is a problem for help. Help can contain topics that are PDF. Browser hangs for about a minute on these. A simple way to try (without any PDF topics): open help, navigate to Platform Plug-in Developer Guide Programmer's Guide Welcome to Eclipse Go to eclipse.org On the eclipse.org click "white paper" link.
Note that a default install of Mozilla does not render PDF either. Changing title of this bug report to focus on the IE PDF freezing issue mentionned in comment 1 item 1). comment 1 item 2): the application needs to handle the WindowEvent as outlined in the WindowEvent javadoc. This PR is to investigate the freeze observed on IE when navigating to a PDF file.
And progress on this problem? Is there any workaround?
*** Bug 76676 has been marked as a duplicate of this bug. ***
Mazen - and other people seeing that problem - can you post the Acrobat Reader version you are using ? (Go to Windows Explorer, open a PDF file on your hard drive, help > about). bug 76676 - occurs with Reader 6.0. OK with Reader 5.0 on XP.
I'm running Adobe 6.0.0 (5/19/2003) on Win2K on my T30 laptop.
W2K/XP Reader 5.0 and Reader 6.0 work fine for me in the Browser. I did not see the dialog that I have seen on Nick's machine that may be related to the problem when going backward in history from a PDF document. Mazen: let us know if you observe the problem with 6.0 or 5.0. Nick found issues on PDF loading and in other cases: PDF is loaded, go backward in history to go to a non PDF URL. This sometimes also takes a long time. Do you observe this as well? On every PDF or just certain ones?
Created attachment 15387 [details] long freeze observed Long freeze obtained on XP - Reader 6.0 - through the Eclipse welcome page - clicking on the eclipse whitepaper pdf file. A dialog finally came up asking to close other Reader instances.
Chris, I'm running Adobe 6.0.0 (5/19/2003) on WinXP on my T30 laptop. so my config is like Nicks, but winXP. The freeze is consistant, and can be reproduced in the Welcome page by doing the steps initially in this defect.
Regarding the freeze when opening PDF documents (note: opening). Can you confirm you observe these 3 points when it happens: 1. Reader 6.0 on the machine 2. No other PDF file previously opened since user logged into the machine (i.e. no AcroRd32.exe in the task list) 3. Freeze/slowness occurs as the Reader 6.0 splash screen draws on the same monitor/screen as the Eclipse Can you also indicate recent versions of Eclipse or SWT that freeze on your box? I can't reproduce with I20041026, 3.1M2, only with I20041005. Changing SWT in I20041005 makes the problem 'go away'. Not happening when self-hosting.
I only see a hang on opening when using the RCP browser example or the file system explorer example (both Eclipse RCP apps). The standalone SWT snippet does not hang on opening for me, but it does on close or when when pressing the back button. I'm running I20041013 with latest SWT and UI from head. Also tried the RCP browser example against Eclipse 3.0, and it hangs as well.
I added some tracing to Display.windowProc. There are a -lot- of WM_NCHITTEST messages coming in as it's opening (like around 35000 of them), but I don't think they are the full cause of the hang. If the window is obscured, these messages stop but it still hangs.
I used Eclpise 3.0.1. Welcome scenario worked when there is no AcroRd32.exe in the task list. However, the back navigation now froze.
Testing Snippet128 against SWT 3.0, I see the same behaviour as in the latest: does not hang on open, but hangs on Back or Close.
I can reproduce with your three conditions met - Acrobar Reader 6.0.0.5/19/2003, Eclipse 200409240800, selfhosting, Windows XP 5.1 build 2600.xpsp2_gdr.040517-1325 : Service Pack 1, Internet Explorer 6.0.2800.1106.xpsp2_gdr.040517-1325. I observere a freeze of about a minute every time a PDF document is selected in help table of contents, in the newly opened Eclipse. There is 100% CPU usage during that time. Subsequently, when switching to HTML document and back to a PDF document, the unloading takes about 5 seconds, but loading PDF again is fast. When doing experimantation, I have tried to swith windows (clicking on the windows task bar), and that created additional problems. Either Eclipse crashed before me coming back to help, or crashed on closing the help shell later on. I have tried latest Eclipse (I20041016) without selfhosting. I have not notice any differences in behavior. Stil freezes and crashes. A stack trace from closing help window is below: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x617F6E0 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at org.eclipse.swt.internal.win32.OS.DestroyWindow(Native Method) at org.eclipse.swt.widgets.Control.destroyWidget(Control.java:509) at org.eclipse.swt.widgets.Widget.dispose(Widget.java:373) at org.eclipse.swt.widgets.Decorations.dispose(Decorations.java:357) at org.eclipse.swt.widgets.Shell.dispose(Shell.java:488) at org.eclipse.swt.widgets.Decorations.closeWidget (Decorations.java:242) at org.eclipse.swt.widgets.Decorations.WM_CLOSE(Decorations.java:1462) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2989) at org.eclipse.swt.widgets.Decorations.windowProc (Decorations.java:1407) at org.eclipse.swt.widgets.Display.windowProc(Display.java:3361) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:1494) at org.eclipse.swt.widgets.Shell.callWindowProc(Shell.java:399) at org.eclipse.swt.widgets.Control.windowProc(Control.java:3069) at org.eclipse.swt.widgets.Decorations.windowProc (Decorations.java:1407) at org.eclipse.swt.widgets.Display.windowProc(Display.java:3361) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:1494) at org.eclipse.swt.widgets.Shell.callWindowProc(Shell.java:399) at org.eclipse.swt.widgets.Control.windowProc(Control.java:3069) at org.eclipse.swt.widgets.Decorations.windowProc (Decorations.java:1407) at org.eclipse.swt.widgets.Display.windowProc(Display.java:3361) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1499) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2446) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1527) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1498) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench (Workbench.java:276) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:144) at org.eclipse.ui.internal.ide.IDEApplication.run (IDEApplication.java:102) at org.eclipse.core.internal.runtime.PlatformActivator$1.run (PlatformActivator.java:335) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:273) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:185) at org.eclipse.core.launcher.Main.run(Main.java:704) at org.eclipse.core.launcher.Main.main(Main.java:688) Dynamic libraries: 0x00400000 - 0x0040B000 C:\jdk1.4.2\bin\javaw.exe 0x77F50000 - 0x77FF7000 C:\WINDOWS\System32\ntdll.dll 0x77E60000 - 0x77F46000 C:\WINDOWS\system32\kernel32.dll 0x77DD0000 - 0x77E5D000 C:\WINDOWS\system32\ADVAPI32.dll 0x78000000 - 0x78087000 C:\WINDOWS\system32\RPCRT4.dll 0x77D40000 - 0x77DCC000 C:\WINDOWS\system32\USER32.dll 0x7F000000 - 0x7F041000 C:\WINDOWS\system32\GDI32.dll 0x77C10000 - 0x77C63000 C:\WINDOWS\system32\MSVCRT.dll 0x76390000 - 0x763AC000 C:\WINDOWS\System32\IMM32.DLL 0x629C0000 - 0x629C8000 C:\WINDOWS\System32\LPK.DLL 0x72FA0000 - 0x72FFA000 C:\WINDOWS\System32\USP10.dll 0x08000000 - 0x08139000 C:\jdk1.4.2\jre\bin\client\jvm.dll 0x76B40000 - 0x76B6C000 C:\WINDOWS\System32\WINMM.dll 0x10000000 - 0x10007000 C:\jdk1.4.2\jre\bin\hpi.dll 0x003A0000 - 0x003AE000 C:\jdk1.4.2\jre\bin\verify.dll 0x003B0000 - 0x003C9000 C:\jdk1.4.2\jre\bin\java.dll 0x003D0000 - 0x003DD000 C:\jdk1.4.2\jre\bin\zip.dll 0x02EF0000 - 0x02EFF000 C:\jdk1.4.2\jre\bin\net.dll 0x71AB0000 - 0x71AC4000 C:\WINDOWS\System32\WS2_32.dll 0x71AA0000 - 0x71AA8000 C:\WINDOWS\System32\WS2HELP.dll 0x02F00000 - 0x02F08000 C:\jdk1.4.2\jre\bin\nio.dll 0x03310000 - 0x0335F000 D:\eclipseI1016 \eclipse\plugins\org.eclipse.swt.win32_3.1.0\os\win32\x86\swt-win32-3110.dll 0x771B0000 - 0x772D4000 C:\WINDOWS\system32\ole32.dll 0x71950000 - 0x71A34000 C:\WINDOWS\WinSxS\X86_Microsoft.Windows.Common- Controls_6595b64144ccf1df_6.0.2600.1579_x-ww_7bbf8d08\COMCTL32.dll 0x70A70000 - 0x70AD9000 C:\WINDOWS\system32\SHLWAPI.dll 0x763B0000 - 0x763F5000 C:\WINDOWS\system32\comdlg32.dll 0x4F510000 - 0x4FD21000 C:\WINDOWS\system32\SHELL32.dll 0x77120000 - 0x771AB000 C:\WINDOWS\system32\OLEAUT32.dll 0x5AD70000 - 0x5ADA4000 C:\WINDOWS\System32\uxtheme.dll 0x63000000 - 0x63014000 C:\WINDOWS\System32\SynTPFcs.dll 0x77C00000 - 0x77C07000 C:\WINDOWS\system32\VERSION.dll 0x03920000 - 0x0394B000 C:\WINDOWS\System32\msctfime.ime 0x74C80000 - 0x74CAC000 C:\WINDOWS\System32\oleacc.dll 0x55900000 - 0x55961000 C:\WINDOWS\System32\MSVCP60.dll 0x746F0000 - 0x74716000 C:\WINDOWS\System32\Msimtf.dll 0x74720000 - 0x74764000 C:\WINDOWS\System32\MSCTF.dll 0x76380000 - 0x76385000 C:\WINDOWS\System32\msimg32.dll 0x03C40000 - 0x03C47000 C:\Program Files\Lotus\Sametime Client\autoaway.dll 0x71A50000 - 0x71A8B000 C:\WINDOWS\system32\mswsock.dll 0x71A90000 - 0x71A98000 C:\WINDOWS\System32\wshtcpip.dll 0x7C890000 - 0x7C911000 C:\WINDOWS\System32\CLBCATQ.DLL 0x77050000 - 0x77115000 C:\WINDOWS\System32\COMRes.dll 0x71700000 - 0x71849000 C:\WINDOWS\System32\shdocvw.dll 0x03F40000 - 0x03FD6000 C:\WINDOWS\system32\WININET.dll 0x762C0000 - 0x76348000 C:\WINDOWS\system32\CRYPT32.dll 0x762A0000 - 0x762B0000 C:\WINDOWS\system32\MSASN1.dll 0x76F90000 - 0x76FA0000 C:\WINDOWS\System32\Secur32.dll 0x75F40000 - 0x75F5F000 C:\WINDOWS\system32\appHelp.dll 0x75E90000 - 0x75F3D000 C:\WINDOWS\System32\SXS.DLL 0x76400000 - 0x76601000 C:\WINDOWS\System32\msi.dll 0x76170000 - 0x761F8000 C:\WINDOWS\System32\shdoclc.dll 0x1A400000 - 0x1A47B000 C:\WINDOWS\system32\urlmon.dll 0x74770000 - 0x747FF000 C:\WINDOWS\System32\mlang.dll 0x71AD0000 - 0x71AD8000 C:\WINDOWS\System32\wsock32.dll 0x76EE0000 - 0x76F17000 C:\WINDOWS\System32\RASAPI32.DLL 0x76E90000 - 0x76EA1000 C:\WINDOWS\System32\rasman.dll 0x71C20000 - 0x71C6E000 C:\WINDOWS\System32\NETAPI32.dll 0x76EB0000 - 0x76EDB000 C:\WINDOWS\System32\TAPI32.dll 0x76E80000 - 0x76E8D000 C:\WINDOWS\System32\rtutils.dll 0x722B0000 - 0x722B5000 C:\WINDOWS\System32\sensapi.dll 0x75A70000 - 0x75B15000 C:\WINDOWS\system32\USERENV.dll 0x0FFD0000 - 0x0FFF3000 C:\WINDOWS\System32\rsaenh.dll 0x51860000 - 0x5188F000 C:\Program Files\Common Files\Microsoft Shared\VS7Debug\pdm.dll 0x51710000 - 0x5173F000 C:\Program Files\Common Files\Microsoft Shared\VS7Debug\msdbg2.dll 0x6B700000 - 0x6B790000 C:\WINDOWS\System32\jscript.dll 0x76670000 - 0x76757000 C:\WINDOWS\System32\SETUPAPI.dll 0x72D20000 - 0x72D29000 C:\WINDOWS\System32\wdmaud.drv 0x72D10000 - 0x72D18000 C:\WINDOWS\System32\msacm32.drv 0x77BE0000 - 0x77BF4000 C:\WINDOWS\System32\MSACM32.dll 0x77BD0000 - 0x77BD7000 C:\WINDOWS\System32\midimap.dll 0x72B20000 - 0x72B38000 C:\WINDOWS\System32\plugin.ocx 0x76C90000 - 0x76CB2000 C:\WINDOWS\system32\imagehlp.dll 0x6D510000 - 0x6D58D000 C:\WINDOWS\system32\DBGHELP.dll 0x76BF0000 - 0x76BFB000 C:\WINDOWS\System32\PSAPI.DLL Heap at VM Abort: Heap def new generation total 896K, used 295K [0x10010000, 0x10100000, 0x104f0000) eden space 832K, 30% used [0x10010000, 0x1004fa60, 0x100e0000) from space 64K, 64% used [0x100e0000, 0x100ea418, 0x100f0000) to space 64K, 0% used [0x100f0000, 0x100f0000, 0x10100000) tenured generation total 10788K, used 8911K [0x104f0000, 0x10f79000, 0x14010000) the space 10788K, 82% used [0x104f0000, 0x10da3fb0, 0x10da4000, 0x10f79000) compacting perm gen total 15616K, used 15398K [0x14010000, 0x14f50000, 0x18010000) the space 15616K, 98% used [0x14010000, 0x14f198e8, 0x14f19a00, 0x14f50000) Local Time = Tue Oct 26 15:50:41 2004 Elapsed Time = 171 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) #
One possible workaround at the moment for those of you experiencing problems with pdf inside the SWT Browser on Windows with Acrobat Reader 6.0 is to: - open Adobe Reader - Edit > Preferences > Internet > Uncheck 'Display PDF in browser' If you still have freeze issues with that settings, please comment. Looking for a reproducible test case and a real fix.
Mazen in comment 13: do you still freeze in 3.0.1 when opening a PDF through the welcome page? Always/sometimes/the first time only? Konrad in comment 15: what are the steps to reach the pdf file from the standalone help? Help > Help content > ?
Some more info: apparently other browsers have similar issues with Adobe Reader 6. Tips range from upgrading to Reader 6.0.2 to disabling certain features of Adobe. This link references a few other links on these topics. http://kb.mozillazine.org/index.phtml?title=Adobe_Reader
It seems to be inconsistant. I just tried with no AcroRd32.exe in the task list. It worked. Navigating back worked. Navigating now forward failed. Empty page in the Eclpise.org frame. Killed welcome. Reopned it. ie: AcroRd32.exe _is_ in the task list. Went to pdf again. It worked! Navigation back worked. Forward got an empty page. ps: This may be a hitory issue with Intro. Remember I do not always rely on the Browser history. Intro has its own history stack. I would need to investigate this as a separate issue.
Nick and everyone with these problems: what is the exact version number of your Acrobate Plugin? (open Adobe Reader > Help > About Adobe...) Mine is 6.0.1 11/3/2003
I still see problems with Adobe Reader 6.0.2 5/18/2004. Problems are inconsistent and I haven't recognized any definite conditions when the problems occur.
As mentioned above, I have 6.0.0 5/19/2003.
Also wrote above, my Adobe is 6.0.0.5/19/2003. Our TOCs do not have a link to a PDF document. To add one, place some PDF document in the doc plug-in (for example org.eclipse.platform.doc.user), and add a topic to the toc.xml in it (add aline <topic label="PDF" href="document.pdf" />). An easier way to view PDF in help without having a document in the TOC is to open help to Platform Plug-in Developer Guide -> Programmer's Guide -> Welcome to Eclipse -> Go to Eclipse.org topic. When Eclipse.org page loads, click the "white paper" link.
Hello I wanted to add to this defect as a team I work on is also seeing this problem and its pretty bad, results in a crash of eclipse with a process dump. weve tried 6.0.0, 6.0.1, and 6.0.2, and even tried tweaking the interest prefs with no solution. What we see is the following, on display of the PDF in an eclipse view, using the browser widget, it takes for ever to load the PDF file, once the PDF file loads, we see an instance of the adobe reader window behind eclipse (I assume its acting as an OLE server). if we close the browser editor, and then close the adobe reader window, game over... crash.... Would love to have this defect bumped in priority.
*** Bug 78567 has been marked as a duplicate of this bug. ***
The severity of this defect should be change to critical or major. Is there a fix for this problem in 3.0.2? It's critical to our product. Thanks!
Raising severity/priority. The current workaround is described in comment 16.
Christophe, are you considering this for 3.0.2? Beth, has your team tried the work around in comment 16?
We need to look at this again for 3.1 to make sure that there is nothing more we can do. Only after fix is known then think about 3.0.2
On a Windows system, comment #16 does work, however on a Redhat Linux system, clicking a .pdf file inside SWT browser doesn't bring up the Adobe Reader. I tried selecting .pdf file from Mozilla browser, it worked, but not from swt browser.
Please open a separate PR for Mozilla. This was never reported as an issue before on that platform.
Beth... What Eclipse version are you using on Linux? You may be encountering https://bugs.eclipse.org/bugs/show_bug.cgi?id=67061 which is a different Linux specific problem. This has a fix in Eclipse 3.0.1, or perhaps you haven't enabled the fix as required. While the title of bug 67061 refers to Flash, the problem also occurred with PDF documents. The 67061 problem applies to the Adobe plugin rendering the PDF in the browser. If you are seeing a problem with PDFs displayed in a separate window on Linux, that would indeed seem like a new problem not yet reported...
Thanks Ron. With fix described in 67061, we were able to bring up the pdf file in a separate window, it appears the download manager download the pdf file and lauched from there.
Created attachment 19586 [details] RCP app and JFace/SWT app to reproduce The RCP application (to launch, start product "pdfviewer.product") shows that closing the editor containing the Acrobat Reader ActiveX takes a long time and uses 100% CPU.
I am having similar problems in my RCP application that uses an Acrobat Reader ActiveX in an editor part. Opening works fine but closing takes at least 20 seconds and the CPU goes to 100%. The strange thing is that this does not happen when I use similar code outside an RCP application, using JFace and SWT only. When I put a breakpoint on org.eclipse.ui.internal.PartPane.dispose() (the line with control.dispose()) and wait a short while, everything works fine too, so this could be a threading problem. I tried with Eclipse 3.0.2 and 3.1M6. In order for people to reproduce this, I attached a simple RCP project (using ActiveX so Windows only). To launch the RCP version, choose product "pdfviewer.product". To launch outside RCP, run the "pdfviewer.Main" class.
We are also seeing this with PDF files contributed by our Help plugins (simple links to printable versions of our Help docs in the TOC), so I am adding myself to the CC list. I'm not sure the status of this, but let me know if you want any more testing done.
The problem could be caused by Adobe Reader and not by SWT. I get the same behaviour with Mozilla (standalone; not embedded in an SWT app) on Windows XP. When I go back from a browser window containing a PDF, or close such a window, Mozilla will often hang and the CPU load goes up to 100%. This never happend with Acrobat Reader 5.
Sorry but my comments in #35 apply to Acrobat Reader 7, not 6. As this bug is about Reader 6, I don't know if this is helpful to anyone, but I thought I would post it anyway. Reader 7 starts up fine but freezes when closing down. The freeze occurs when OleClientSite.onDispose calls deactivateInPlaceClient(). Tracing Windows Messages with Spy++ is enough to make it work. A hack that works is to make Display.windowProc wait for 1 millisecond for each message while OleClientSite.onDispose calls deactivateInPlaceClient(). Alternatively, adding an empty System.err.println() in Display.windowProc works too. While I know this is not very elegant, it works for my application and also for Eclipse Help as described in comment #1. This does not improve anything for Reader 6 however.
Adriaans, thanks a lot for your feedback and the RCP test app. We're using it for testing that problem. We're also looking at partial workarounds with 'sleep(1)' techniques as a way to help with Reader 7, possibly for the next milestone. A good surprise would be to have Reader 8 works as well as Reader 5 used to. If 'sleep(1)' is the best workaround we can get for the 3.1 release then so be it. No luck with Reader 6 at the moment. So if you have anything in that area, we're always very interested.
At the moment, we have only seen the Reader problem in RCP/Eclipse based applications, not in standalone SWT apps. e.g. the standalone web browser application works fine but the same as a view inside Eclipse shows the problem with Reader 7 when unloading a PDF. If anyone has a standalone SWT app that shows the problem, please let us know.
v>20050419 We have released a partial 'workaround' that fixes 2 cases on our machines here. - Reader 7.0, web browser 'back' button freezes when unloading PDF - Reader 7.0, web browser freezes when closing and PDF displayed (Adriaans's RCP app now works here, the 'fix' is similar to his) It will be in next week integration build (I20050426) Otherwise, comment 16 describes how the user can workaround that problem on their machine. Keeping PR open to continue to get feedback and keep track of future versions of Reader Acrobat.
Downgrading to P2. There is a fix in place for some of the cases.
*** Bug 127392 has been marked as a duplicate of this bug. ***
Downgrading to P3. We have done all we can here.
We can confirm that the partial workaround in comment 41 works with Acrobat 6.0. Note that only the problems mentioned in comment 41 are fixed (slowness of Back button and dispose).
Closing since we have done all we can.
Since this bug was marked fixed now, is there any new check-in after partial fix of the problem comment #41? Thanks.
No there haven't been changes since then related to this.
