Browser Behavior Change

14 posts by 5 authors in: Forums > CMS Builder
Last Post: March 26, 2019   (RSS)

By KennyH - February 28, 2019

Something recently has changed with either Chrome or CMSB. Now, when you are arranging sections (Dragging / Dropping) at CMS Setup >Section Editors the "Update Password" box from Chrome keeps popping up. Another problem that sprang up recently is that at least one regular text field tries to autofill with a username and/or password for fields that have nothing to do with usernames or passwords.

I know Chrome updates frequently but after toying with settings and tons of searching for answers, I can't seem to get this to go away without disabling the password feature on chrome or some other sacrifice I really don't want to make. 

I cannot duplicate this problem on 3.12 or 3.15. It just happens with 3.50, so this leads me to believe that something changed in CMSB.

Any ideas?

Thanks in Advance! 

Kenny

By daniel - March 5, 2019

Hi Kenny,

Regarding the password popup, I haven't been able to replicate this issue on my machine; I'm running Chrome Version 72.0.3626.119 and following the steps on a CMSB 3.50 installation. Could you check your Chrome version (under Help > About Google Chrome) and see if your version matches, or if there are any updates available? 

For the auto-fill, is this a text field defined in a section, or something that's part of CMSB? Browsers generally auto-fill by looking at the HTML of the field (name, type) and making its best guess as to what it might contain. Unfortunately, this isn't always infallible and there can be false positives. If it's part of a created section, you can try to change the Field Name, or if it's part of CMSB core we can look at that specific field.

Let me know if you're able to make any progress, or have any more questions.

Thanks!

Daniel
Technical Lead
interactivetools.com

By KennyH - March 5, 2019 - edited: March 5, 2019

Hi Daniel - 

I am using the latest Chrome and CMSB 3.50 when this happens. When I use 3.15 or earlier, it's all good. It happens on some of the fields I create, but the most annoying one is in the Section Editors. I can be under the General tab doing some work and it will fill in my username under the Advanced tab >> Max records per user. I don't even click on the Advanced tab so I didn't notice this was happening for a while.

Now, many of my websites have this in their settings '_maxRecordsPerUser' => 'MyUsername',

It doesn't break anything, but it is highly annoying to have my username inserted into the settings without my notice. I have to go in and take it out every single time I click save while modifying the section.

For some reason, I don't have the option to block Google from saving passwords from these pages. I think in previous versions of Chrome, you could select "Not for this site". In any case, that would get cumbersome for having to put in a block for the 100+ websites that I manage with CMSB.

I'm not sure what to do at this point. Maybe requiring '_maxRecordsPerUser'to be a number might help for this particular field. Examples of the names of fields I have created where the username starts auto-filling is facebook_numeric_id and address_2

I also see it happening at Plugins>CSV Import - Import File under the 2nd screen where you map the fields >> Create Menu >> Menu Name fills in my username automatically. Is my Chrome going rogue or what?

Thanks,

Kenny

By daniel - March 6, 2019

Hi Kenny,

Thanks for the reply. It turns out that Chrome now bypasses the original measures we had taken to prevent autofill in the CMSB admin. I'll be adding an updated fix to the next CMSB release, but for now, you can do this relatively simply yourself. In /lib/common.php look for a block that looks like this:

    $html .= "\n<!-- Attempt to disable autocomplete for browsers that ignore HTML5 autocomplete standard -->";
    $html .= "<input type='password' style='display:none'/>"; // originally from: http://crbug.com/352347#c11
    $html .= "<input type='password' style='display:none'/>"; // 3 password fields seems to prevent built in password functionality from activating (in Chrome)
    $html .= "<input type='password' style='display:none'/>";
    $html .= "\n";

And replace it with the following:

    $html .= "\n<!-- Attempt to disable autocomplete for browsers that ignore HTML5 autocomplete standard -->";
    $html .= "<input type='password' style='display:none'/>"; // originally from: http://crbug.com/352347#c11
    $html .= "<input type='password' style='display:none'/>"; // 3 password fields seems to prevent built in password functionality from activating (in Chrome)
    $html .= "<input type='password' style='display:none'/>";
    $html .= '<input style="display: none;" type="password" name="password" autocomplete="new-password" />'; // https://stackoverflow.com/a/15917221 
    $html .= "\n";

It's curious that the behaviour has changed for you between versions, as this code hasn't changed recently, but hopefully, this update will resolve your issue.

Let me know if this works out for you!

Thanks,

Daniel
Technical Lead
interactivetools.com

By KennyH - March 6, 2019

That fixed the problem! Thanks!

By kitsguru - March 6, 2019

You should remove the / on the input as that is now incorrect for  HTML5

Jeff Shields

By Deborah - March 11, 2019

Hi, Daniel.

I replaced the suggested code on several sites running 3.15 and am experiencing an issue for all of them.

Everything functions great with the suggested code until I go to Background Tasks and select the 'clear all' link. What happens then (on all sites I had updated), is the site immediately displays the "welcome website visitors" message referring to the database disconnection, followed of course, by the site going offline.

I traced this down to the /data/settings.dat.php file database password is completely removed... ( 'password' => '',) when Background Tasks are cleared.

I've reverted back to the original /lib/common.php for all sites, so no emergency here. Maybe you could check at your end?

~ Deborah

By daniel - March 14, 2019

Hi Deborah,

Thanks for reporting this issue! However, we are having some difficulty replicating it. Do you have any sites on 3.50 that you could try this on, or are you able to upgrade one of your 3.15 sites to 3.50 to see if that corrects it? That could help us narrow down our search.

Thanks!

Daniel
Technical Lead
interactivetools.com

By Deborah - March 15, 2019

Daniel,

I appreciate you checking into this. All I can add now is that it happens regardless of the browser used, so what I'm experiencing is not specific to Chrome.

I'll install a 3.50 test and give it a try, then post back with results by early next week.

~ Deborah