-
Notifications
You must be signed in to change notification settings - Fork 114
Does not seem to play nice with ui-router #12
Comments
@gerob311 Have you tested this in other browsers? I am seeing a similar issue, but it seems to only happen in Chrome? Safari and Firefox seems to work fine. |
I'm encountering this same exact issue. Seems to only be happening in Chrome. Any update regarding this? |
Managed to do a quick fix for now. I'm preventing the pdf viewer to update the window title by manually setting PDFViewerApplication.isViewerEmbedded to true. This works for my current configuration. |
@ciriac so far, your quick fix in Chrome seems to work, thanks! |
Managed to do a quick fix for now. I'm preventing the pdf viewer to update the window title by manually setting PDFViewerApplication.isViewerEmbedded to true. This works for my current configuration. Where should this be put? I'm having the same issue. Routes are not working correctly. |
@bw7432 This needs to be done in the source file of pdf.js. The library does not expose this option. It's just checking if the window parent is not equal to window and this does not play nicely with Angular's ui-router. Search for this line (should be around line number 16301): And change it to: |
@ciriac, thanks for clarifying. Works perfectly, thanks so much! |
any updates on this? Could we set it to true in pdf.js-viewer or pass some config somehow. (This library is a bower component in my project and all components ignored in git). Thanks. |
Added it to our TODO list. |
Any news on this issue ? Same situation than @alexburkhay ... Thanks |
Hi there ... is that option available now ? I am experiencing this same thing and I do not want to edit the vendor file. |
I was trying to use this directive in an application that has several ui-router states. I'm using the directive inside a dialogue box that could be opened from any state.
After using the pdf viewer, any state transitions would kick me back to my initial state, making the application unusable until the page was refreshed. I did notice that after opening the pdf viewer, it would change the title in the browser tab from the application's name, to the title of the pdf that was opened, and I checked a stack trace that seemed to imply that fireUrlChange() was causing the unexpected state transition. I was not able to determine why though.
The text was updated successfully, but these errors were encountered: