Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi, I'm trying to make it easier for users by setting the focus on the first input element within a popup. Apparently this code should do the trick, but I'm not sure where I should put it. Tried various things, but no avail.
$('input:first').each(function(){
this.focus();
});
Much regards,
Marius
Comment | File | Size | Author |
---|---|---|---|
#19 | 385732-popup.js_.patch | 664 bytes | matason |
#13 | omgjqueryisawesome.patch | 1.53 KB | RobLoach |
#5 | popups.jpg | 11.97 KB | mariusooms |
#4 | popupfocus.patch | 1.53 KB | RobLoach |
#2 | popupfocus.patch | 849 bytes | RobLoach |
Comments
Comment #1
sirkitree CreditAttribution: sirkitree commentedI would most likely put it inside a
Drupal.behaviors
which is re-applied upon a popup call. I would also target this inside of the #popups-body as well. So overall it would look something like this:Not sure you really need to go through each one since you're only specifying the
:first
.Comment #2
RobLoachJerad's right. This gives focus to the first enabled input element in the popup window after the popup window is created.
Comment #3
mariusooms CreditAttribution: mariusooms commentedLooks good, unfortunately it didn't work ;(
There is only one textarea in the form and no other input fields so it should plain work. I added your code in my own skin js file and seems to load fine in head.
Thanks for the help regardless,
Marius
Comment #4
RobLoachThis one is nicer.
Comment #5
mariusooms CreditAttribution: mariusooms commentedHi....thanks for looking at this, patch applied flawless. I can't believe I get hung up on something that should just work *bangs head on desk*...It refuses to focus on the textarea. See attached screenshot. I also tried the other skins, but no luck.
The textarea is nested but that shouldn't stop the jquery to find the selector?
I'm at a loss...
Regards,
Marius
Comment #6
RobLoachIf you enable the Popups Administration module, and visit some of the administration pages, is it providing the focus correctly? It's working here.
Comment #7
mariusooms CreditAttribution: mariusooms commentedNope neither. Tried different themes as well. Awkward to say the least. I trust it works (code is just fine in theory), will let it slide since I can't prioritize it now. Hopefully on other projects I will have better success. Debugging this one is...well...nearly impossible as it should just work.
Thanks guys,
Marius
Comment #8
starbow CreditAttribution: starbow commentedI will have to double check, but I think there is already code in popups.js that is supposed to do this.
Comment #9
RobLoach@starbow: The patch at #4 fixes the code in popups.js.
Comment #10
starbow CreditAttribution: starbow commentedhmm, actually it is an interesting issue. Right now we are checking for inputs, but we also need to be checking for textareas and selects. And then we need to determin which comes first.
Comment #11
starbow CreditAttribution: starbow commentedOr maybe not. The 1.3 specs say :input should select them all.
Don't know how to get the 1.2 docs on my phone.
Comment #12
mariusooms CreditAttribution: mariusooms commentedWell I'm really glad that, even in my unsuccessful venture for my install, it did enhance this module. So it wasn't all in vain!
Also...my issue is not due to the module, I tried to call this function separately from the module, but did not work either. So my search continues...
Veni,vidi, (eventually) vici.
Regards,
Marius
Comment #13
RobLoachGood call on :input.
Comment #14
mariusooms CreditAttribution: mariusooms commentedomgrobloachisawesome.patch! It worked now. I didn't realize either that you had to specify :input rather than input.
Thanks for the help! I can safely say that this is working 100% now.
Regards,
Marius
Comment #15
starbow CreditAttribution: starbow commentedGreat!
Although the patch removes the todo // TODO: capture the focus when it leaves the dialog.
Which is still a pending item. Right now, if someone tabs off the last form element in the dialog, they end up on the page in the background, which kind of kills the illusion of modality. I want to add a little code to loop them back around from the last :input to the close link and then to the first :input. But I am not sure the best way to distinguish between a tab triggered blur and the user clicking somewhere else.
Comment #16
starbow CreditAttribution: starbow commentedHere is what I ended up going with:
Comment #18
idontknowtheanswer CreditAttribution: idontknowtheanswer commentedHi,
Sorry to reopen this but it seems the right place. Can we get an override for this default behaviour? Whilst it's great on some forms I have one form using the jquery datepicker which binds to an input element. The effect of automatically setting focus to this element causes the datepicker to show once the form is open which isn't desirable.
Can I suggest something like an additional class I can specify on my input element that forces the refocus method in popups.js to ignore it?
TIA.
Comment #19
matason CreditAttribution: matason commentedHi,
Have attached a patch that will prevent focus on elements with class="no-focus" set.
Comment #20
NaX CreditAttribution: NaX commentedFor anybody else that finds this issue because they ran into trouble setting focus on a textarea.
There seems to be a problem with resizable textareas not accepting focus being set on them. I think the problem is that the Drupal core textarea js file removes the focus.
The way I got around it is to ether disable resizing
EG:
$form['body_field']['body']['#resizable'] = FALSE;
Or to set my JS in the footer so that it runs after the core js files.
EG:
drupal_add_js(drupal_get_path('module', 'my_module') . '/my_scripts.js', 'module', 'footer');