I am loading the pdf.js viewer in my webpage in a div using the pdf.js API methods such as run and open.
In this page I also have a file upload section to attach related documents.
The issue is when I upload a document in the file upload section, using dropzone, the pdf viewer thinks I am uploading a document to it and changes the existing document. Is there a setting to turn this off? I thought there would be something in network.js but I haven't found anything promising yet.
Here is the offending part in PDFViewerApplication, it adds a global change event listener and changes the pdf if it's a file input with files selected.
Unfortunately there is no settings flag to disable this behaviour, no reference to the listener function to remove it, and also no way to cancel or change the event (it would also break other parts of the app), so you'll have to modify this code to remove it. Seems like the listener just dispatches a new internal fileinputchange event which is only used for this, so you only need to comment out this line.
Related
I am trying to migrate my extension which records screen/tab/window according to the chosen option from manifest V2 to V3. In manifest V2 I was able to use background script as persistent and reach html page objects such as mediaRecorder, navigator. However in manifest V3 background script works as a service worker. So, I have to start the screen record in content-scripts to be able to reach the html objects. When I start chrome.desktopCapture API from the background script, I have to start the screenRecord in one of the tabs (should give a tabid to chrome.desktopCapture.chooseDesktopMedia API call). I cannot start it on the background page and when the page was refreshed or changed to a new URL screen record stops. Is there any workaround for this?
I believe the best way to handle updates such as a URL change on a tab is to attach the onUpdated listener to the chrome tabs in the background script.
chrome.tabs.onUpdated.addListener(function(tabId, changes, tab) {
//Detect Type of Change and Handle Accordingly
});
There are quite a few other events that may be of use that are listed in the chrome documentation Chrome Tabs Events. It's also possible to inject inline JavaScript from the content script so you can access the pages window object directly and attach event listeners there to handle reloads or URL changes. Check this stack overflow post for more information Modify Window Object in Chrome Extension
Using PF10 (in a JoinFaces project), I'd like the Upload File dialog for choosing a file to show up when the page loads (i.e., without waiting for the user to click on the Choose button of <p:fileUpload/>). How can I do that?
You could use client side API show() function for this. But it seems more and more browsers are blocking triggering a click by script on an input type="file". See https://github.com/primefaces/primefaces/issues/7772
You could take your chances and try to hijack a mouse move event to trigger a click on the upload input, which is answered on this question: In JavaScript can I make a "click" event fire programmatically for a file input element? But I don't really like that hack.
I am working on a Firefox Extension, using the SDK. The addon will be changing the CSS on specific websites (by attaching a stylesheets in the head). They obviously need to be attached before the main content of the page loads.
I need to be able to listen for the URL of a tab changing, and attach a script, before the tab content has loaded. The script will wait until the <head> has loaded before attaching the stylesheets.
I tried using tabs.on('ready', function(tab) { tab.attach(...) } ), but this does not work, because it listens for the tab to be fully loaded, and then runs the code inside the function()
I also tried pageMod, but this does the same as the above. It attaches to the pages I need it to, but only after they are fully loaded.
Does anyone know how to detect for a tab URL change, before the page is ready?
Note: Please do not answer with a setInterval() method, I cannot state this enough!
I worked out how to do it, I had not read the pageMod documentation well enough.
You can specify when the script is attached, using contentScriptWhen: "when", where when can be start, ready or end (obviously I used start)
How can I make a Chrome extensions that is not a popup or a button?
I wanna have a script running whenever the window is opened and iterate thru all its tabs performing actions on each tab.
I also need (is this possible?) want to add to the same extension buttons (+keyboard shortcuts?) that when clicked, perform actions on all tabs.
Then I need control on these buttons visibility, and make them visible only in certain conditions (e.g. show only when page is loading, hide when not-loading).
Where do I put my script and how do I refer to it in my *.json manifest?
Any info/links will be appreciated.
The answers to 0 and 1 can directly be found in the documentation, specifically background pages, chrome.windows API and chrome.tabs API.
To bind global events, use the chrome.experimental.keybinding API. Because this API is experimental, you have to enable it first at chrome://flags. Also, the extension cannot be uploaded to the Chrome Web store.
If you want to add an "extension button" which performs some action on click, define a browser action and bind an event listener to chrome.browserAction.onClicked.
To select all tabs, use chrome.tabs.query({}, callback) method ({} means no filter, so all tabs are selected).
Browser action buttons are always visible. If you want to create a button which is not always visible, use a page action instead. The chrome.tabs module includes several events which can be used to find out whether your conditions are met.
As for putting up the script and the manifest file, read the documentation on Manifest files and explore some examples.
If I don't implement any updateready event handler and don't call swapCache(), does that mean that the browser will always use the first (oldest) downloaded version of the application?
If no, then why is the swapCache() method needed?
Swapcache makes sure that "subsequent" calls to cached resources are taken from the new cache.
Subsequent meaning after swapcache.
To see this in action try setting the src property of an img dynamically after the
swapcache call in the updateready event (so that the browser loads it at that particular
time). Make sure this image is not already loaded elsewhere in the page since that will
distort this test.
Now change the image and change the manifest files (to force reloading the cached files).
Reload the page in your browser.
You should now see the new version of the image in your rendered page.
Now comment out the call to swapcache.
Make a change to the manifest file and reload the page and thus all resources.
Refresh the page again (to make sure you have a version from the new cache).
Now change the image again and change the manifest.
Again reload the page: now you see the old version of the image.
In the last case, the browser finished loading the new versions in cache, but since
swapcache was not called, the image was still taken from the old cache.
If you do not do any dynamic loading of resources in your page, the swapcache has no effect.
In particular, if you reload the page in the updateready event handler calling swapcache
first has no effect since reloading the page will get it from the new cache anyway.
I have an app with a pretty large cache (>100mb). This takes a particularly long time to swap the cache in (and pretty much locks the browser while this is happening). So I display a message indicating that the app is updating (please wait...), then call swapCache(), then display a new message when it's done indicating completion.
Not sure if this answers your question (as to why it's necessarily needed), but I think it provides a valid use case for swapCache() at least.
Let's imagine 2 different scenarios.
You call location.reload() when the new content is available. The page will reload using its all-new content. applicationCache.swapCache() is not needed in this case.
Your user continues to interact with your page, without any reload. This interaction causes an asset to load dynamically. For the sake of argument, let's imagine that it's a rollover image, and let's imagine that you have just updated this rollover image. Without applicationCache.swapCache(), your user will continue to see the old rollover image. After applicationCache.swapCache(), s/he will see the new rollover image.
So applicationCache.swapCache() without a reload says: "Keep the page looking the way it was when it was loaded, but use any new assets now, as soon as the page asks for them".
The SwapCache method provides a mechanism for the application to be in control of how an when updates are applied. In regular HTML apps, it can be difficult to determine if the correct JS is present on the clients browser.
Also browser implementations vary on when a cache would be updated, I found the iPhone particularly stubborn. swapCache put me back in control of how my app is updated i.e. I could choose to automatically apply the patch or let the user choose when to apply etc.
I was wondering the same thing. I seem to be able to trigger a successful update by just calling "window.applicationCache.update()". If the manifest file has been modified, the 'download' event is triggered, then eventually the "update ready".
When I reload it, it appears to have been applied. I don't seem to need to call swapCache(). I have provision for calling it from the app, but so far have not noticed any effect on the update process.
Calling update() basically eliminates one reload, AFAICS.
swapCache will switch from the previous set of resources listed in the cache manifest (when the running webapp was loaded) to the new set. You are doing this in response to an updateready after all, which signals that a new manifest has been loaded.
This is not to be confused with loading individual resources, for which the usual browser caching policies still apply. In other words you will swap set of resources, but individual resources need their own cache management to ensure they're reloaded when you need them to.
I haven't tried this yet, but it would seem to suggest structuring the code as an "update controller" javascript file that handles the update process, and javascript sources with a versioned filename (or URL) with known entry points.