After upgrading to 2.2.0, <input> tag 'readonly' attribute is not rendered

[jancurn]

Hi there, after I upgraded blaze@2.1.9 to blaze@2.2.0 in our Meteor app, the 'readonly' attributes on tag are no longer rendered. This only happens if the tag has some dynamically generated attributes, for example:

<input type="text" readonly value="{{todo.text}}">

This one works correctly:

<input type="text" readonly>

I replicated the problem also in "Todos" example app. I cloned the repo from https://github.com/meteor/todos, updated meteor and all packages to their latest versions and have the same problem (actually I tested the above code in Todos app). When I downgraded to blaze@2.1.9, readonly attribute is rendered (although not as boolean attribute like 'disabled', but that's another story). Strangely enough, other attributes like 'disabled' are rendered normally.

[mitar]

So this might be related to #102. @gcacars, could you take a look?

@jancurn: could you make a pull request with a test to Blaze to test for this case? Are we missing a test for this?

[jancurn]

re @mitar: I will try to add some test, although not sure when I find time for it :-/

[thearabbit]

I have the same problem

// Work fine for blaze 2.1.9, but now don't work
{{> afQuickField name='branchId' readonly=true}}

How to fix?

[gcacars]

I done some tests with my project.

Template.login.helpers({
    attrs(){
        return {
            readonly: false
        };
    },

    test(){
        return false;
    }
});

<input class="form-control" type="text" name="username" {{attrs}} disabled="{{test}}" required>

Any helper like disabled (helper in attribute) works fine.
But nothing in attrs works correctly.
I think that Blaze do something different with dynamic attributes.
@mitar Could you help with this? Where in the code Blaze treat this.

I also test an input like jancurn said:
<input type="text" readonly value="{{todo.text}}">

For me works fine.

[thearabbit]

Thanks, but I use AutoForm so I can't use like this

Template.login.helpers({
    attrs(){
        return {
            readonly: false
        };
    },
});
--------
{{> afQuickField name='branchId' attrs}}

Could you help me?

[mitar]

@gcacars: Maybe here or here?

But where does your pull request interfere with that?

[thearabbit]

Now I downgrade to 2.1.9

[bluefangs]

@thearabbit - Could you please tell me how you downgraded to 2.1.9?

[thearabbit]

please look in

.meteor/
   versions

And then find the blaze@2.1.9

[jancurn]

hey guys, I wanted to write a test for this bug, but I wasn't able to find out how to run tests in this project...

[mitar]

One approach is explained in #70. What I do is I configure METEOR_PACKAGES_DIRS to packages directory of this repository. And then I run from a package I am testing (like blaze):

meteor test-packages ./

[gcacars]

@mitar I put a break point inside Blaze._makeAttributeHandler and BooleanHandler but nothing hits both break points, I don't know why.
I will take a look in this HTML.flattenAttributes.

[gcacars]

With the same example, the debug shows me:

The first object is the attributes declared in HTML. But disabled have a null value here (in helper, this value is false, but I think that helper do your job later). The second object is the dynamic attributes, with readonly false as set in helper object.

But HTML.isNully don't interpret the value false as nully, adding it to the list that render attributes. So HTML is still rendered in the wrong way with readonly="false".

The final result object is:

Blaze._makeAttributeHandler (pull request change) never was called. (nor Blaze._materializeDOM, materializeTag, (function that call _makeAttributeHandler) and so on... could be because of Iron Router?)

[gcacars]

Maybe other commit is impacting. checked is not working too.

[mitar]

@gcacars: Any progress on fixing this?

[serkandurusoy]

People are reporting success with changing the attribute name from readonly to readOnly, which makes sense since that's the actual name on the dom object when fetched using the javascript api.

So if perhaps this is a case sensitivity issue, can't we just make the name comparison in

blaze/packages/blaze/attrs.js

Line 285 in 95d68da

Blaze._makeAttributeHandler = function (elem, name, value) {

case insensitive?

[Netherdrake]

I can confirm that:

        autoform: {
            readOnly: true
        }

Works fine, but only on String input types.

[bluefangs]

@mitar - Safe to upgrade to the latest version without any modifications? (readonly to readOnly) ?

[mitar]

I hope so. :-) 2.2.1 should work the same as 2.1.9. But I would love feedback. :-)