Why doesn't event.relatedTarget work with focusin/focusout event in Firefox? - firefox

I need to find the previously focused item in my focusin function. Here is an example code:
$('#id').on('focusin', function(event) {
//console.log(event.relatedTarget.nodeName); //doesn't work
}
I've done some research and while I've seen some people saying in posts that this only works with mouse events like mousedown etc., I've come across a few articles from reputable sources that have me believing this should work.
https://developer.mozilla.org/en-US/docs/DOM/event.relatedTarget Here Firefox specifically mentions how event.relatedTarget returns "which EventTarget is losing focus" in the 'focusin' event.
Firefox is the browser I am using for this.
http://www.w3.org/TR/DOM-Level-3-Events/#events-FocusEvent at this bookmark you can see that every FocusEvent has a readonly attribute called related target.
http://www.w3.org/TR/DOM-Level-3-Events/#event-type-focusIn Here they specifically state as well that the 'FocusEvent' has a property called 'relatedTarget' which is "event target losing focus (if any)."
So then what am I doing wrong here? It must be some kind of dumb syntax mistake or something. I cannot find the nodeName of event.relatedTarget.
Update: I can get it to work in IE using, but this won't work in Firefox???
$("#id").on('focusin', function(event) {
$('#textbox').text(event.relatedTarget.nodeName);
}

Although MDN mentions relatedTarget for the focusin /focusout events, unfortunately, no version of FireFox actually supports those two events. jQuery simply emulates them for you but due to lack of native support, you don't get relatedTarget on FF.
See compatibility info here or here.

Related

Domino on mac client - weird doc behavior

I support an old (late 90s) Domino DB that has a growing number of Mac users. In some docs, layout regions become grayed out once you click anywhere in the doc even though it's still editable, i.e. if the cursor was in a text field and you type something blindly and save it, it will be there when you reopen the doc. It doesn't happen in all docs and I have found no pattern.
Any Domino designers seen any behavior like this? I don't this there is anything too weird in the code; onBlur or onChange used in some cases - that sort of thing. Nothing too complicated really. Thanks!
Layout regions are a nightmare to maintain: there can be objects with differing hide-when formulas stacked on top of each other that might be causing this. I suggest making a copy you can work in without worry: inspect each object fully (keeping notes) then delete. Keep drilling down until you hopefully hit an object that matches your grey-out. If you don't find one, then it could be a bug as posted by Richard Schwartz. As Richard and D.Bugger suggest, perhaps it's time to rebuild the functionality without using a layout region: layout regions never worked with a web browser.

Respond immediately to textarea changes in Dart

I've got this in my html file:
<textarea id="inputbox" placeholder="type here"></textarea>
What's the correct way to wire up a handler that will fire immediately whenever the content of the textarea changes? (whether by keyboard, mouse/clipboard, speech input, brainwave reader, etc)
I tried:
query("#inputbox").on.change.add(handler)
but (at least on Dartium) it only fires after you tab out of the field.
The purpose is to update a "live preview" window, similar to the way Stackoverflow renders Markdown output while you type.
This is the best I came up with so far. I'd be happy to hear if anyone knows of a more compact or preferable alternative.
Edit: Code snippet updated to the new pattern for event registration.
import 'dart:html';
void main() {
query("#inputbox")
..onChange.listen(handler)
..onKeyDown.listen(handler)
..onKeyUp.listen(handler)
..onCut.listen(handler)
..onPaste.listen(handler);
}
void handler(Event event) {
print((query("#inputbox") as TextAreaElement).value);
}
The precise behavior will vary between browsers and operating systems.
You could skip keyDown, but be aware keyDown and keyUp behavior is influenced by the OS and isn't guaranteed to be symmetric. You might conceivably miss a change, at least until the next keyUp or change event gets fired. Indeed I proved this out by creating a little app on Windows 7 to send an orphan WM_KEYDOWN message to Dartium and IE9.
keyPress could be used instead of keyUp and keyDown, but won't generate events for certain keys like backspace and delete.
cut and paste react immediately to a cut or paste performed with the mouse. If you don't use them, the change event will capture the change, but not until after the field loses focus, or sometimes even later.
The input event could replace all listeners above and seems to work great in Dartium, but under IE9 it only captures character additions, not removals.
Note keyUp and keyDown may generate additional unwanted events for cursor keys, home, end, shift, etc. (e.g. In IE9). It will fire in addition to the cut/paste listeners when the user uses shortcut keys for those actions.
While the question is specific to Dart, a lot of the discussion above applies to any code listening to the DOM. Even keyCode values aren't standardized across browsers (more detail).
It may also be worthwhile checking out the KeyboardEventController class, though by and large when I tested it the edge case behavior was similar to that noted above. That may or may not be by design. The Dart developers do make some effort to insulate you from cross-browser inconsistencies, but it's still a work in progress.
Also while we're talking about textarea, remember to use its value property, not its text property. Finally, be sure your handler throttles its reactions to "bursts" of keyboard activity (e.g. some sort of timer that briefly defers the guts of your handler and rolls up any additional events which occur in the meantime).
Related questions and links:
Handle events in DART
Handling Keyboard events in Dart Language
How do you listen for a keyUp event in Dart?
Cross browser key event handler in Dart
jQuery example that skips keyboard events and binds to propertychange
Its not clear if you are using polymer or not, but if you are, you can subscribe to a change to a variable annotated with #observable by creating a function in the polymer element in the form as [variable name]Changed(oldvalue). I originally found this here: How to subscribe to change of an observable field

hoverIntent not working

I've been battling with this for ages now, just can't seem to get it right.
The hoverIntent plugin isn't working, but hover is.
Here it is on jsfiddle.
This is a common problem that everyone has when using hoverIntent, which is why I generally try to avoid it.
I had the same problem initially, hover() from JQuery doesn't work same way as Brian Cherne's hoverIntent(). It requires two functions (instead of a choice of one or two): one for hovering in and one for hovering out. Since you defined the object to slidedown, you have to define what it should do once the user hovers his/her mouse out. If you don't want it to do anything, you can create a dummy function function(){}. You may have to change other components in your html too.
Here's a similar post: jQuery hoverIntent not working, but hover does
Make sure you also have your javascript files implemented correctly and in the correct directory. Hope this helps!

Getting Windows Phone 7 WebBrowser Component VerticalOffset

I want to persist the user's location in the document he or she is browsing, then bring them back to that spot when they return from tombstoning or between sessions.
My first approach was to wrap the browser component in a scrollviewer, but it turns out it handles its own scrolling and the scrollviewer never changes its verticaloffset.
My guess is that the browser component must have a scrollviewer or something like it embedded in it. I need to get the verticaloffset and scroll to an offset.
Any guesses how to get there?
My next approach would be a painful mish-mash of javascript and c# to figure out where they are...
Because of the way the WebBrowser control is built you'll need to track scrolling in Javascript then pass the location to managed code to handle storage of that value.
On resuming you'll need to have the managed code pass the scroll position to a Javascript function to reset the scroll position.
That's the theory but I haven't looked at the funcitonality around javascript scrolling events in the WebBrowser yet. That's the only place I can see possible problems.
Would be good to hear how you get on.
I've accepted Matt's answer, but I want to put in some details here. I'm also going to blog about how I did it once I'm completely done.
Since the WebBrowser component is essentially a black-box, you don't have as much control as I would like. Having said that, it is possible to get and set the vertical offset.
Javascript lets you ask for the value, but different browsers use different variations on HOW to ask. For THIS case I only have one browser to worry about.
First I make a couple of simple javascript functions:
function getVerticalOffset() {
return document.body.scrollTop;
}
function setVerticalOffset(offset) {
document.body.scrollTop = offset;
}
Next I call into the WebBrowser using the InvokeScript method on the browser object.
I'll post an update here with a link to my blog when I get the full write-up done.
I have been writing an eBook reader and had a similar question. Code for setting a scroll position has been easy enough to find.
Code for setting vertical scroll position:
string script = string.Format("window.scrollBy(0,{0});", "put your numeric value here");
wb_view.InvokeScript("eval", script);
Google didn't help much in finding solution for getting the value of current scroll position. Lacking any knowledge in javascript it took me almost two hours to get it right.
Code for getting the vertical scroll position:
var vScroll = wb_view.InvokeScript("eval",
"var vscroll = window.pageYOffset; vscroll.toString();");

Colored iCal style checkboxes using Cocoa

Is there a way to get colored checkboxes like in iCal without using custom drawing?
I have looked through the documentation but can only find how to change the background and text color.
You can achieve something at least similar to the colored checkboxes in iCal by enabling Core Animation for the checkbox and adding a "Hue Adjust" (in "Color Adjustment") content filter. If the color is static, this can be done entirely within Interface Builder, no code needed.
Be careful, though, as sometimes enabling Core Animation for various views causes strange bugs (for example, WebViews don't play nice with Core Animation views).
If you want to do it programmatically, take a look at the documentation for CIFilter (that's a link), which you use with the NSView instance method setContentFilters: (also a link).
It's a bit dated (runs back on 10.3), but Matt Gemmell published a some code for doing colored checkboxes a few years back.
http://mattgemmell.com/source
Look for "iTableView."
I looked at the code when it was first available, but not since. There might be a better way to do it at this point.
I'm afraid not. I'm not sure if the AHIG forbids this sort of thing or not, (it probably does), but the reason iCal gets away with it is because, 'Hey! Why not?'. Also, it's an Apple application, so yeah.
It can still be done, of course, but not without custom drawing. Personally, I'd advise against it, and rather see if what you are trying to achieve could be achieved some other way. If not, you could possibly use some of the data files from iCal to build your checkbox. (Unsure of how kosher that would be, but 'Hey! Why not?'.)

Resources