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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sirkitree’s picture

I 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:

Drupal.behaviors.selectFirstInput = function() {
  $('#popups-body input:first').focus();
};

Not sure you really need to go through each one since you're only specifying the :first.

RobLoach’s picture

Status: Active » Needs review
FileSize
849 bytes

Jerad's right. This gives focus to the first enabled input element in the popup window after the popup window is created.

mariusooms’s picture

Status: Needs review » Active

Looks 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

RobLoach’s picture

Status: Active » Needs review
FileSize
1.53 KB

This one is nicer.

mariusooms’s picture

FileSize
11.97 KB

Hi....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

RobLoach’s picture

If you enable the Popups Administration module, and visit some of the administration pages, is it providing the focus correctly? It's working here.

mariusooms’s picture

Nope 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

starbow’s picture

I will have to double check, but I think there is already code in popups.js that is supposed to do this.

RobLoach’s picture

@starbow: The patch at #4 fixes the code in popups.js.

starbow’s picture

hmm, 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.

starbow’s picture

Or 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.

mariusooms’s picture

Well 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

RobLoach’s picture

FileSize
1.53 KB

Good call on :input.

mariusooms’s picture

Status: Needs review » Reviewed & tested by the community

omgrobloachisawesome.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

starbow’s picture

Great!

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.

starbow’s picture

Status: Reviewed & tested by the community » Fixed

Here is what I ended up going with:

/**
 * Set the focus on the popups to the first visible, enabled form element, or the close link.
 */
Drupal.popups.refocus = function() {
  // Select the first visible enabled input element.
  var $focus = $('#popups :input:visible:enabled:first');
  if (!$focus.length) {
    // There is no visible enabled input element, so select the close link.
    $focus = $('#popups-close a');
  }
  $focus.focus();
};

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

idontknowtheanswer’s picture

Hi,

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.

matason’s picture

FileSize
664 bytes

Hi,

Have attached a patch that will prevent focus on elements with class="no-focus" set.

NaX’s picture

For 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');