Fix conflict between OpenID login form and contact form

reproduced.
the username field on the leftbar remains, and the your name field of the contact form disappears. see screenshot.

normally the username field id is edit-name, but on the contact page it's the 'Your name' field that gets the edit-name id. The username field is edit-name-1 and therefore the 'Your name' field is hidden instead of the username field.

here's a patch for the contact module form which resolves the bug. However, maybe openid.js should be fixed too.

Attached a patch which hopefully fixes the problem. The jquery selectors are now more specific.

Okay, my patch at #5 only fixes part of the problem. The username field isn't removed because as correctly mentioned by scor in #3 the id for the login form gets changed. This will probably happen on other pages and/or with other modules too and isn't restricted to the contact module.

Drupal will make sure each id is unique (which is understandable to be xhtml compliant), but because of this, which id an element gets assigned is kind of unpredictable in some rare cases like this.

Simply giving the username and password fields of the login form different id's is a possibility to fix this problem, but I doubt it's a good approach since some themes might depend on the id's.

The best thing is probably through some clever jquery selection rules for openid.js?

#5 is not right - if nothing else, the login block and /user login page have different ids for the form, so no the code doesn't attach on the /user page.

Also, this change fails to hide the username field, even in the block, when on the contact form page because of the change in id addressed by my patch above.

this patch should take care of all aspects of the bug.

Okay, another patch... This one uses a different jquery selector which, at least with the little testing i've done, seems to work.

#7 pwolanin: I know the patch in #5 doesn't solve the problem, see my previous post.

This patch takes a little different approach and would cover the case of a conflict in the password field as well. It wraps the user and password in the class "openid-hideable" (feel free to come up with a better name) and changes .js to hide all divs in that class. Not sure which is the best approach.

Wow, three choices. How about just changing the id used for the contact form. I think all the solutions are doing more than they should.

Since the login form may be present on almost every page for anonymous, fix the form that's less likely to be seen. It would have minimal impact that way.

Fix the form that is more likely to be seen, rather - 'name' fields are very likely to be strewn throughout contrib. The behavior that is breaking is OpenID's, so if you leave this in, you'll get a ton of bug reports into openid.module that you would need to identify and move to the appropriate contrib module.

I reviewed #8 and would say it's rtbc, maybe with the changes of #9 incorporated. I don't think #10 is a good solution because it does not solve the duplicate ID problem.

looks like gdevlugt and I cross-posted twice.

@dvessel here's a more minimal patch as you suggest

@kkaefer: There are no duplicate IDs in practice - Form API now spits out valid XHTML. The problem is that it does this by attaching a "-{n}" suffix to duplicates, which means that the dynamically generated HTML will have IDs not predictable by a static Javascript file.

Because of this, using a class wrapper may be the more sensible approach here.

@Arancatar, you have a very good point about #12. None of the patches posted solves that issue. 'edit-name' is very generic and to fix that, all instances of 'name' would have to be changed or something like patch #9 with partial ID matching.

@pwolanin, it fixes the problem but I think it's still fragile. As kkaefer mentioned, incorporating #9 would be more bulletproof or changing all $form['name'] which might be a bit much ATM.

But note that the selector used in #9 is off.

not:

#user-login-form div[id*='edit-name-']

but:

#user-login-form div[id^='edit-name']

Note the appended dash and ^ == starts with while * == contains.

[edit: the selector is fine, never mind me. It's looking for 'edit-name-*wrapper'. Was thinking plain 'edit-name' and 'edit-name-NUM'.]

[second edit: #user-login-form div[id*='edit-name-'] would also select #edit-name-wrapper + #edit-name-NUM-wrapper and "#edit-name-NUM". It doesn't look like a good solution.]

It seems we should change the selectors for both name and pass. Though edit-pass seems less likely in a form presented to a non-logged in user having the two be consistent would be a plus and having a solution that doesn't rely on an unchanging ID.

#16 dvessel, second edit:

Not correctly true.

First it operates only on the user login form (#user-login-form)

Second, you mention it operates on #edit-name-1. The only possible occurrence of that id is in an input field (on the user login form that is), however, the selector only works on divs (div[id*='edit-name-'])

@Dvessel - look at my last patch in #14 - the other patch breaks openid.js on the user login page

gdevlugt, your right. My bad.

I combined pwolanin's approach with gdevlugt's. It shouldn't break in the login page or anywhere else.

There was a bad selector to for getting rid of the "error" class. It was present in your patch pwolanin and mine since I copied you.

.fixed

While form element IDs are unpredictable, every input can be identified by a combination of the form ID and the input name. This would seem cleaner: $(prefix + "input[name=name]")

How is an "OpenID form on a contact form with JS turned on misbehaving" is a critical issue? Sounds like a corner issue (which would be great to be fixed, but certainly not a release stopper).

@nedjo - can you roll that patch?

#22 nedjo: That's true, but in openid.js, the wrappers around the input name and labels are being referred to, not the actual input fields. My jQuery knowledge is pretty basic, but afaik, there's no way to refer to the input name's parent wrapper right?

jQuery uses CSS selectors, which are top-down, but it also implements a parent() function.

$('input#input-id').parent() would give you the direct parent of the item. I recommend against this - access the wrapper directly, it's a lot safer. Traversing a DOM relatively can lead you astray with some browsers in quirks mode.

Now using the selector nedjo mentioned.

Confirming that this is still a problem with Drupal 6.19.

This bug is also present in Drupal 7

Looks like a duplicate of #897794: OpenID login link can hide the wrong fields. That issue is much newer than this one, technically that is the duplicate, but it has a fresh patch.