Not all supported NuGet references are being linkified

[xt0rted]

Browser name: Chrome

Browser version: 64

OctoLinker version: 4.16.1

URL and line number where issue occurs: equineexchange/EquineExchange.ImageHosting@3a91729#diff-f2c1409a20722ddaf5705add38f2fbe1

Expected behavior: The NuGet packages should be linkified like they are elsewhere such as equineexchange/EquineExchange.ImageHosting@de36584#diff-f2c1409a20722ddaf5705add38f2fbe1

Actual behavior: The NuGet packages are not linkified like they are in other diffs

I've worked on the NuGet references but I don't have the time right now to look into this. I wanted to report it in case someone else might know what's causing the issue.

I've been noticing this in a lot of my recent PR diffs. Sometimes the diff will contain say 8 files that contain NuGet package references, but only 2 or 3 of them will actually be linkified. In other cases all the files are. It's happening in both my packages.config and *.csproj files.

[stefanbuck]

Maybe related to #338

[leomoty]

This one is very strange, opening the URL yields no octolinks whatsoever. but clicking View in packages.config and then pressing history back, it works. @stefanbuck any hints here?

[stefanbuck]

Indeed, this is very strange and I can't think of anything which is causing this behaviour. I think it's best follow the same debugging steps as described in #510 (comment) Let me know if you need additional help. Thanks for looking into this @leomoty

[leomoty]

Hello @stefanbuck, @josephfrazier,

I have been quite busy at work, but got a bit of time today, I figured out the issue, it might be related to #338.

It is not an OctoLinker issue per se, we are handling it fine, however, some blobs are not loaded with the document. This is loaded by javascript afterwards:

https://github.com/equineexchange/EquineExchange.ImageHosting/diffs?bytes=17873&commentable=true&commit=3a917291b3e2ad459d2ed84af96b6245658758bf&lines=372&sha1=5d20a77c8f23b17b181ee84bb425395a8414bb2f&sha2=3a917291b3e2ad459d2ed84af96b6245658758bf&start_entry=10

If you disable javascript you'll see this:

I don't know the best solution, but we need either to defer the octolinker.init() call or do something like we did with #505.

A friend suggested something alongside these lines: https://gist.github.com/BrockA/2625891, we might need to rethink BlobReader to not visit the same blobs over and over, could even benefit #505?

[xt0rted]

GitHub uses selector-observer and delegated-events to wire up their JS because of how parts of the site load (mostly PJAX). I'm not familiar with how Octolinker is setup but maybe this pattern is what's needed to get these other sections to work?

[leomoty]

@xt0rted, this is the relevant line:

https://github.com/OctoLinker/OctoLinker/blob/master/packages/core/octo-linker.js#L85

injection invokes the callback directly and should also run at pjax:end. I didn't tinker much with it.

[leomoty]

I wonder if the extension is rerunning at pjax:end at all? the call has a VARY: PJAX header.

[stefanbuck]

It should re-run on pjax:end, but maybe they changed the way how the lazy load snippets and pjax:end isn't invoked anymore.

https://github.com/OctoLinker/injection/blob/master/index.js#L12

[leomoty]

Yeah I noticed that as well.

[leomoty]

Also that being the case, when you expand a deleted file, the content wont get octolinked, right?

[stefanbuck]

Seems to be working fine now. Feel free to reopen the issue in case it's still an issue