Fragment (anchor #) in .NET 4 WebBrowser Control getting lost with Adobe PDF Reader and file://

2
votes

I create an URI with a fragment (aka anchor #). 

UriBuilder ub = new UriBuilder("file://path/doc.pdf");
ub.Fragment = "chapterX";

The url is shown correctly in the debugger (ub -> file://path/doc.pdf#chapterX). But when I assign it to a WebBrowser control, the fragment part gets lost (reason for the fragment see PDF Open parameter).

this._myWebBrowser.Url = ub.Uri;
// Alternative this._myWebBrowser.Navigate("file://path/doc.pdf#chapterX");

When I check this._myWebBrowser.Url it displays file://path/doc.pdf. this._myWebBrowser.Url.Fragment is empty - also readonly and cannot be assigned.

As C.Haas has shown below, the concept works in general, for some reasons it fails when the resource is a LOCAL(!) pdf file.

Summary:

  1. Works if protocol is http
  2. Works if resource is .htm / .html - even when protocol is file://
  3. Works if file is .pdf and protocol is http (same as 1.)
  4. Fails if refers to local pdf file, fragment gets lost

Any workaround for this?

Revisions:

  1. 20110219 - Update thanks to C.Haas. As Chris shows, OK with ".htm", but fails with ".pdf" and only if it refers to a local resource.
  2. 20110218 - Some finding thanks to abatishchev: If I use Navigate it does not work neither, but Navigate offers to provide a frame name. In this case an external IE pops up (because there is no frame in the control's page) and then the URL with fragment is correctly displayed. Is not what I want, but it shows me the URL itself is correct and the bug seems to be within the control.
1
.netpdfwebbrowser-controlparameter-passingacrobat
I removed C# and Windows Forms tags because the navigation (and thus the url parsing) is implemented by the hyperlink frame in adobe's ActiveX document server. The hyperlink frame provides partial document display, download progress, cancellation ability, etc. For more information about webbrowser's role in hyperlinks to ActiveX documents, check msdn.microsoft.com/en-us/library/aa740928(v=VS.85).aspx – Sheng Jiang 蒋晟
Thanks for the feedback, but I do not think it is correct. IMHO it is the underlying .net class (most likely UriBuilder) cutting of the fragment. Otherwise I'd see the full URL in WebBrowser.Url - or am I wrong? I do have the theory that the underlying class provides some intelligence - thinks the resource is a local file and therefor ignores the fragment. Because if I use a different protocol (not file://) the fragment remains. So it is likely a .net (of course not pure c#) issue, not an issue of the ActiveX control. – Horst Walter
You are right in the aspect, that it is not an issue of the control, but the Uri class then. But since it looks this happens in combination of control and Uri class, I have tagged it with both. Again, thanks for the feedback. – Horst Walter
What is the final url in DocumentCompleted? Do you get DocumentCompleted at all? – Sheng Jiang 蒋晟
The event DocumentCompleted is called, the WebBrowserDocumentCompletedEventArgs.Url is without fragment (file://path/doc.pdf) while navigate was called as follows: Navigate(file://path/doc.pdf#chapterX). – Horst Walter

1 Answers

1
votes

How about

wb.Navigate("http://example.com#chapterX");

?