Autocomplete popup positioned 2.5em lower in "Seven theme" using Firefox

This doesn't happen when I test it using a tags autocomplete box on Windows/Firefox 5.0, Windows/IE 8.0, Linux/Firefox 3.6.18, or Windows/Safari 3.2.3 - I'm not sure if that indicates that the particular location of the autocomplete box I've tested it with just isn't in the same place and circumstance as yours.

Can you elaborate on the exact parameters of the autocomplete box you're using, so I can see if I can replicate the problem? The .png seems to suggest it's custom code?

I tested that site on the same set of browsers, and again don't see the displacement of the autocomplete box - it pops up exactly where it's supposed to. I think we need more input from some other people to see if anyone else can replicate this, because I can't get it to occur.

Bug confirmed.

Is it able to fix autocomplete.js calc the right top margin instead dependence on other elements ?

(EDIT: YES, ONLY FIREFOX HAS THIS BUG.)

always fix head version first.

I don't see why we should fix that in the JS, so I guess the seven patch should do it.
I'm no themer though, so setting to needs-review for others.

I've encountered the problem with Firefox 3.6.18 on Ubuntu and Firefox 5.0 on Windows.
The Seven CSS Patch fixes the problem without creating new problems on other Browser(I've tested it on Safari 5, Opera 11, IE 9, Chrome, Fifo 5 on Windows and Fifo 3.6.18 and Chrome on Ubuntu).
I also don't see the need for the JS Fix.

Just like a modules, less dependence is always good for it.

e.g. adding position: relative;, it limited someone using position: absolute on .form-item to theme the elements.

Im more like fixing in this way (attached patch)

I can confirm this is happening in FF 6.0.2 on Mac OS 10.6.8.

I have tried both the css and js #11 method and both work, however the css method is too broad as it applies the positioning to all instances of .form-item which may have implications.

It seems to me that a better solution would be (as in #11) to replace

$($input).parent().css('position', 'relative');

with

$($input).parent().addClass('autocomplete-wrapper');

and add some css to system.base.css

.autocomplete-wrapper {
  position: relative;
}

I have tried this and it works fine.
This way themers can override and everyone is happy ;-)

I will leave patch building to those more closely involved with core than I am.

I ran into this in bartik. Perhaps the issue's Component should be changed to the form system?

In Drupal 7.12, the autocomplete was positioned at the top left of the window using windows Firefox 10.0.1. It positioned correctly IE9. Placing it in a relative positioned div as described above worked.

#11 works perfectly, I was experiencing this on both Firefox and Chrome with a custom modal window that contains some node references.

#11 solved the issue for me. Tested with:
Drupal: 7.14
Browsers: Firefox 15.0.1 for Ubuntu, Chromium Version 20.0.1132.47 Ubuntu 12.04 (144678)
Themes: Seven, Bartik

This was an issue for me in D7. When having an autocomplete field in Bartik I was finding the following behaviour:

• In Firefox the popup was appearing above and to the left.
• In Chrome and Opera it was not appearing (it was off the page below right).
• In IE it was working normally.

#11 fixed it in all browsers, although I think you can just say $input.parent(). $($input) is redundant.

Thanks.

#11 with the change recommended by Rob230 (just $input) did the trick in my 7.15 installation.

Drupal 7.22 patch from #11 work for me Firefox and Chrome

I think good idea from @hutch in #16

Patch in #11 worked perfectly! Thank you :)

Also Bartik. #11 worked for me. Thanks!

Added link to attached image.

#16 mentions some problems with #11 which need to be addressed.
We will need a patch to be committed to 8.x before a 7.x patch will be considered.

Is this still an issue? I wasn't able to replicate it in D8. Core's changed so much that the patch is irrelevant at this stage for D8.

It is quite possible that with leveraging jQuery UI's autocomplete that this problem has been fixed in D8.

Which brings us back to D7 and the patch in #11.

Autocomplete has been replaced in D8, so it's not surprising that you can't reproduce this any more. It does still need to be fixed on D7 though (assuming this is the same issue as #2132107: The autocomplete drop-down in the related issues section of the issue edit form pops-up far from the field... or can otherwise still be reproduced)

D8 using jQuery UI now, should not have any problems.

I don't want to repeat my word but seems like most commenters just look at the last patch #11. And Yes. Both #10 & #11 sorted the problem. However, I still think my patch #10 is the best solution right now. Because it lets themer to add "position: absolute" to the parent element. (jQuery UI does the same way)

Patch #11 doesn't address this problem. Comment #16, moving style only let CSS guy theming it easily. On Patch #11, when you adding "position: absolute" to parent, it's broken again.

Add it back

10: autocomplete2.patch queued for re-testing.

I prefer the approach in #10, but it will likely break when inside a CTools modal dialog because they override the top property via JS. A new bug will have to be created in the CTools issue queue when this is committed.

I found the duplicate (with patch similar to #16)

I've got a patch on #2157907 for 7.x (mentioned in #33) which I believe is very unobtrusive and allows for easy overriding. Here's a summary:

The patch in #2157907 fixes the bug by positioning the autocomplete popup's parent element relative while the popup is open.

This is achieved by defining "position: relative;" for the class "autocomplete-parent" in system.base.css and adding that class to the autocomplete popup's parent element (via autocomplete.js) when the popup is open. When the popup is removed, so is the class on the parent element.

So the fix basically shows up only when it's needed and works via class toggling (no inline styling) so it's completely override-able.

I can roll an 8.x patch if this sounds like a good route.

@chrisolof,

Read #29

@droplet - Good catch - I, for some reason, thought this was an 8.x bug. I'll try and test your patch in #10 against the issue I outlined in 2157907, as they're probably related. If it doesn't fix both issues I'll probably just re-post my patch here too.

I can no longer reproduce this bug on my system, nor can I reproduce the related bug I outlined in #2157907. I'm thinking this may no longer be an issue for users on current browsers.

@chrisolof,

this is for D7. We still have to fix it for older browsers. :(

It is not clear to me which patch is being marked RTBC (#10 or #11), what testing has been done, or whether any of the discussion above has been resolved....

I also can't reproduce any issue here (using Firefox 50 on Linux). If it does turn out this was a browser bug which Firefox fixed in more recent versions, I don't see any reason we need to do anything about it on our end.

I reviewed 7.69 on simplytest for both chrome and firefox. Here is what I did:
* add terms: term1, term2, and term3 to the Tags vocab
* add new article (tag field has widget set to Autocomplete term widget (tagging))
* select terms

Here is the simplytest link for those that see it in the next 24hrs, https://stm5e0a0cb299bb8-jqirou3dubgkwotuzdxnhrjgshgxmlvd.tugboat.qa/.

I believe this can be closed as it no longer seems to be an issue.