I see a lot of event listener breakpoints on the devtools, but not "download" or such.
I want to trigger a break on file download, is it possible through a setting or a program/JS?
download isn't an event in JavaScript, hence, you don't see it in the event listener breakpoints section. However, you can set a listener on XHR/Fetch calls, which would pause execution when the browser tried to fetch something.
More info:
https://www.canidev.tools/debug-xhr-fetch-calls/chrome
Related
Everything about the uploader is working perfectly, but one callback seems to do nothing:
.bind('fileuploadchange', function (e, data) {
console.log("foo");
})
Binding to the change event never returns anything... so my question:
1) Is this a bug? I'm using the most recent version.
2) Is there another/better way to detect when files are manually removed from the upload queue (something more elegant than reading DOM elements)?
There might be a bit of misunderstanding in what the fileuploadchange event does.
The admittedly limited documentation for the change event states:
Callback for change events of the fileInput collection.
That means it's an event callback for the native change event of all the file input elements of the fileupload widget.
This event only fires if the user selects one or more files via the file picker dialog that is displayed after clicking on the file input button.
Technically, the basic fileupload library doesn't keep track of a queue.
It's up to the UI implementation to handle this, via the various callbacks provided by the basic library.
Until the user actually starts the file upload, there is technically nothing the basic library could keep track of.
And as soon as a file upload is started, the done and fail events are your basic building blocks.
By the way, the sample UI implementation handles the removal of items that have not been started yet by triggering a manual fail event.
According to Google's app lifecycle docs
When the event page has no executing JavaScript, no pending callbacks, and no open windows, the runtime unloads the event page and closes the app.
I am seeing in my app that an onSuspend is being triggered, which also has the side effect of invalidating any FileEntry or DirectoryEntry references (an as-of-yet undocumented "feature"), only the onSuspend is triggered when I still have pending callbacks and open windows. Does anybody know which other conditions will trigger an onSuspend? Does it have to do with the app using too much memory?
It makes sense that onSuspend will be called when the event/background page has no activity and there are no windows open, but when else would onSuspend be called?
Is there a secret permission that I can use to disable onSuspend from being called? A background permission API in the works?
It should not be triggered if you have open windows unless something atypical is under way, like the user upgrading chrome.
If you are seeing onSuspend events at other times, that sounds like a bug. Please report at crbug.com with steps to reproduce.
I got into a trouble, because my plug-in want to open file dialog when using command+o,but the safari holded on this event.Anyone has a solution?
I strongly suspect there is nothing you can do about this; as a plugin you are a second class citizen, a guest in the process.
You can accept the command event, you have to listen to set a callback for the event member of NPPluginFuncs struct in NP_GetEntryPoints method.
In that method you'll receive all mouse and keyboard events, as well as window focus events. You can cast the second argument from void* to NPCocoaEvent where you will find all necessary parameters suchs as event type, mouse state, keys and focus data.
Please check which event type you're handling before digging into the 'data' union of NPCocoaEvent, otherwise you can get an EXC_BAD_ACCESS.
I'm having trouble with sharing commands with the browser, in my case Command+O should fire the plugin's file open dialog only, but it's also firing the browser open file dialog. Supposedly, returning TRUE for event handling method should report the browser that the plugin handled the event, but I'm having no luck yet.
Part 1: Expected behaviour?
I'm seeing some inconsistent browser behaviour between Firefox and Chrome in relation to the onclose handler being called.
It seems that Chrome does not trigger an onclose if it was caused by a user page navigation/refresh. However, Firefox does trigger the onclose.
It seems to me that Firefox may be behaving correctly here:
When the WebSocket connection is closed, possibly cleanly, the user agent must create an event that uses the CloseEvent interface, with the event name close, which does not bubble, is not cancelable, has no default action, whose wasClean attribute is set to true if the connection closed cleanly and false otherwise, whose code attribute is set to the WebSocket connection close code, and whose reason attribute is set to the WebSocket connection close reason; and queue a task to first change the readyState attribute's value to CLOSED (3), and then dispatch the event at the WebSocket object.
Source: http://www.w3.org/TR/2011/WD-websockets-20110419/#closeWebSocket
Even though it can lead to some sneaky code/unexpected behaviour.
Can anybody confirm the expected behaviour?
Part 2: How to implement auto-reconnect?
If you have a library that auto-reconnects for the user how do you know if you should try to reconnect? Do you check the CloseEvent.wasClean property? I'm having to assume that 'clean' means that the close was supposed to happen through either an API call to WebSocket.close() or the server sending a close frame? If a network error causes the close I'm guessing the wasClean would be false?
In the Pusher JavaScript library we assumed (onclose -> waiting -> connecting) that a close should trigger a reconnect unless we are in a closing state - the developer has chosen to close the connection. It would appear that the socket.io client library makes the same assumption.
Based on this the Firefox onclose event caused by user navigation/refresh triggers an unwanted reconnection because neither library check the CloseEvent.wasClean property.
Example and Video
Here's an example that you can use to demonstrate the inconsistency:
http://jsbin.com/awonod/7
Here's a video of me demonstrating the problem:
http://www.screenr.com/vHn8
(it's late, ignore the couple of slip-ups :))
One point to note is that my hitting the Escape key could also be causing the WebSocket connection to close. However, if you watch closely or try for yourself you will see the close event being logged just before the page refreshes.
The unexpected behavior is due to the way in which Firefox and Chrome handle the closing of a Websocket. When the page is refreshed, both browsers close the connection, however, Firefox will execute your onclose code, while chrome closes the connection and skips straight to re-loading the new page. So yes, I confirm this strange behavior.
Even stranger is the fact that, from my observations, calling websocket.close() in chrome will immediately close the connection and call the onclose function, while Firefox waits for a close message back from the server.
The wasClean property will be true if a close message was received from the server
If your library is auto-reconnecting without checking the wasClean property then this could cause a problem, as it tries to re-establish the connection as the page refreshes. You should consider not using the library for this and doing it manually, it should'nt be very hard, just call connect in the onclose function with an if statement making sure the onclean property is true. Or to be even more safe set a variable in onbeforeunload that prevents any new connection.
hope this helps!
This is amazingly still the current behavior in 2022. You can demonstrate this trivially by adding a console log in an onclose handler for a websocket, and click a link in Firefox vs in Chrome while watching the console (ensuring you preserve the console between webpages):
ws.onclose = function(e) {
printMsg('CLOSE')
// ... my other code ...
}
Firefox will show you a 'CLOSE' and Chrome will not.
Selenium's open command implicitly waits for the whole page to load, including images, etc.
How do I just wait for the DOM to load, like jQuery's .ready() method?
Currently, I'm using waitForElementPresent, but is there a better alternative?
I think you may try to do the following
Tweak the selenium source code to stop it raising page reloaded flag.
Use custom command or getEval to check if the dom is loaded and proceed.