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.
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.
Beginner / Intermediate developer here and trying to get a grasp on tracking down event listeners, but finding myself confused and frustrated because it always point to the library that handles the event, not the user's script. Example from the Event Listeners accordion on a select element that has the "keyup" event bound:
keyup
div.select
handler: function (e){return typeof b===i||e&&b.event.triggered===e.typet:b.event.dispatch.apply(f.elem,arguments)}
isAttribute: false
lineNumber: 3
listenerBody: "function (e){return typeof b===i||e&&b.event.triggered===e.type?t:b.event.dispatch.apply(f.elem,arguments)}"
node: div.select
sourceName: "https://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"
type: "keyup"
useCapture: false
Obviously they are using jQuery, and they're doing a damn good job of it by using jQuery's $.extend method, but I still don't understand why the events accordion (in dev tools) would point to the library rather than the customized script?
Is there something really basic I missed in class? What methods are there for tracking these types of things down aside from CTRL+F in the Resources tab, which, btw did not yield any search results for "select" in the file that ACTUALLY extends/adds this listener - very odd is it not?
Update: So I feel pretty dumb about this, but the answer was right in front of my eyes - or so I think. At the top of their custom script they begin with,
define(["jquery"], function($) {
Could this be the beginning of the answer? Really what I'd like to understand is why the event would still trace back to the library when the event listener is bound within the above code,
$el.textHolder.click(function(e){
... do stuff ...
}
As far as I understand, this is because when jQuery binds an event, it doesn't bind it directly to your code, but instead to jQuery code that then dispatches the event to your code.
The Chrome devtools don't know (at this point, it seems to be in development) how jQuery binds the event, so only shows the first handler (jQuery).
The define call is part of the CommonJS Modules Standard I believe. See also RequireJS
If I use a dialog to create an instance of an entity, will it fire the plugin registered to that message (i.e. Create on EntityA)?
If not, how can I link that plugin to that message?
Yes, the plugin will always fire regardless of the source of the message.
You're safe to use the plugin. It will catch the dispatched message as long as you've registered it correctly.
The plugin will, in fact, react to the following events.
Creation of an instance (a record) by the user from the GUI.
Creation of an instance by a workflow.
Creation of an instance by a dialog.
Creation of an instance by a code from an extern program.
Creation of an instance by... anything.
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.