Linked definitions going to top of Lexicon

[missyschoenbaum]

This is minor, but when you click on one of the links on a definition, it goes to the top of the Lexicon instead of going to the exact definition like it used to. I doubt the links changed.

[ConradSelig]

@missyschoenbaum I cannot seem to find any links that are not working as expected - can you point me to one that is not working for you?

[missyschoenbaum]

@ConradSelig Maybe I should clarify to make sure we are on the same page. Originally, if I clicked on a link (zone) I would be taken directly to zone in the lexicon.

Now, when I click on zone, instead I go to the top of the lexicon.

[missyschoenbaum]

I assume the link is written to go directly to zone and it appears zone still has a link.

[ConradSelig]

Could you paste the link that the app gives you when you press either of these two buttons?

The links are working just fine for me but having a broken link may help me locate the bug.

[missyschoenbaum]

I don't see the link, I get the page with this header.

[ConradSelig]

Looks like it has something to do with how the app viewer is handling urls. @BryanHurst would you advise on this? I don't know anything about how the production app is being handled.

[ConradSelig]

We decided during the meeting we would try to track down why we started using the built-in viewer to load the wiki page instead of using the user's native browser. If the reason for switching is no longer important to us we will instead switch the links to start opening the user's default browser.

[ConradSelig]

Looks like using the default browser was the original action of the wiki links (evidence of this found in #245). This seems to have been changed as part of #307. Unfortunately I'm not sure if anything in #307 is still useful to us - it does not look like the links are still formatted the same way (There are no links that start with localhost address).

By #674 the wiki pages were being opened in-app. There is a commit in here that might be useful for figuring out how the viewer is loading the pages.

Long story short I haven't found any ticket that talk directly about switching from using the default browser to the viewer. I'm going to take a closer look at the code for a bit and see if something jumps out at me.

[ConradSelig]

I don't think I'm the right developer for this job. I'm not already equipped with enough of an understanding of how the app is being deployed through CEF. I could learn what I would need to know to fix this bug, but it would take likely 10-15 hours before I could even start writing code.

However, I have managed to snag and adapt a snippet of code that will do what we need (I believe) if it can be implemented correctly. Here is the function. It "needs to be implimented in the RequestHandler class in CefSharp.Example package."

bool IRequestHandler.OnBeforeBrowse(IWebBrowser browserControl, IBrowser browser, IFrame frame, IRequest request, bool isRedirect) { // If the url is Google open Default browser if (request.Url.StartsWith("/Lexicon-of-Disease-Spread-Modelling-terms#")) { // Open Google in Default browser System.Diagnostics.Process.Start("/Lexicon-of-Disease-Spread-Modelling-terms#" + url); return true; }else { // Url except Google open in CefSharp's Chromium browser return false; } }

Thanks to Aharned Salik and Murat Aykanat for writing the base functions I adapted to create the above function.

Another problem with this approach. url will need to be collected from somewhere, easiest solution would likely be to regex it out of the wiki() function already in place to generate the links, or to rewrite the wiki() function to simply return the url instead of a built html string.

Sorry I'm not more help on this!

[missyschoenbaum]

It's not the end of the world it we can't fix it. It gets to near the right place.

[BryanHurst]

This is fixed with a new Viewer application from #961.

[missyschoenbaum]

Looks good!