-
-
Notifications
You must be signed in to change notification settings - Fork 213
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create Pages/Menus > Enter Page Data and Saved Username is in Menu Name #3131
Comments
Seems like the issue is not new. https://productforums.google.com/forum/#!topic/chrome/f6zhGC8lVw4 There is a suggestion to add to form tag autocomplete="off" |
Thanks @MikeyGMT ! Yeah, perhaps we can add autocomplete="off" by default on all forms. |
Seems the fix is autocomplete="false" I am just testing now. |
Hi Cameron! I have changed to false in the form handler, but did not work. I am looking further into it. |
But WC3, IE and FF require On/Off https://bugs.chromium.org/p/chromium/issues/detail?id=468153#hc41 |
I have added a comment to the latter chrome bug. I guess the workaround is drop or rename the page password field or recommend folk not to use chrome. |
I tested disabling the page password and chrome still autofills. FF is working correctly. I guess we can close this unless anyone has any bright ideas. |
I've read through this https://stackoverflow.com/questions/7223168/how-to-trigger-autofill-in-google-chrome/9795126#9795126 and the links within it, and there's lots of clever stuff to identify fields which are potentially autofillable, but I am not fully understanding how we can specifically prevent autofill. https://www.w3.org/TR/2010/WD-html5-20101019/the-input-element.html#concept-input-mutable for example, isn't written in the clearest language! What I got from it was probably a long shot, but maybe label could help us. Our code does not have label for input fields, instead we have a span. More importantly, labels are essential for screen readers used by visually impaired users.
This is the array for menu. |
@MikeyGMT Does changing |
Hi @CaMer0n,
It is quite a big impact change, a few folk need to test thoroughly. Maybe others can test by making that change locally? If it really does work, it would improve screen-reader compatibility enormously across all e107 websites. |
It did not fix it, it is still convinced this is a username field in chrome. But I think it may work if we add the for=menu_name but I am not sure how to do that. |
OK, so added for=".$keyName."
Rendered code is correct, but still chrome is assuming menu_name is a variant of user_name, because there is a password field. I tried adding a user_name tab option field in cpage to fool it, but nope, no luck. |
OK, so I have found a workaround, change the lan CUSLAN_64 to Menu Code or menu_code (in fact, it is more accurate to call it "menu_code") - and the field tab option name to menu_code, everything else is set back to today's git. Menu Name somehow get's attributed to user_name. Bizarre, you should read the google bugs, people are getting (quite rightly) very irritated with the issue.
|
Oh dear, it breaks all over the place. Will need menu_name replacing in 23 files! Who knows in plugins and themes. This is not a valid workaround. "You must enter either a page title or a menu name." Quick fix tried was changing from text to textarea, not working. Played around with other settings, no success. Nearest fix seems to be to rename menu_name to menu_code. |
Seems to me change the name of the menu_name field or maybe consider this https://github.com/terrylinooo/jquery.disableAutoFill |
Thanks Mikey! Or maybe chrome could fix their bug. smh. |
It seems this tip worked: https://gist.github.com/niksumeiko/360164708c3b326bd1c8#gistcomment-3004386 Pushed it, and tested on the latest Chrome and Firefox. @Jimmi08 could you test please? |
Looking good! |
I looks fixed. PHP 7.3 Excellent job. Thank you. |
Annoying little browser issue. When creating and editing Pages, in chrome, at least, the username appears in the Menu Name. I'll check in other browsers.
Makes it a wee bit clunky for new users...
Or worse creates a new menu/page hybrid instead of page.
This is the inspect source:
<input type="text" name="menu_name" value="XXX_username_XXX" maxlength="255" id="menu-name" class="tbox form-control ui-state-valid" pattern="^[a-z0-9-]*" data-original-title="" title="" aria-describedby="tooltip991890" autocomplete="off">
Really this should be a fresh issue. But from a usability point of view, I would like to see Create/Edit Pages and Menus split into separate functions, as they are in the new user's head different, well, to me as well. If I am showing a new user how to edit / create pages, then have to explain that you ignore the menu bit, you get a blank face, and they say ... "Oh I don't know, I am not very technical, can I leave it to you?". Which is what I want to avoid, it's their site to update. If you see what I mean.
I would not know where to begin, to split them myself, so won't attempt it. :)
The text was updated successfully, but these errors were encountered: