http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=33040&start=0

Can you have a look at this PR: #2531
It should solve this isse as well.

hi,
yes your pr fix this too. but i think if you fix this issue like mine, it is better, because some developers use readonly="true" or disabled="true". this is popular for all fields. but in your PR developer must use readonly="readonly" or disabled="disabled".

True, but yours would set them to true as soon as you set the parameter. Even if you set it to 0 or false.

I think I didn't change that part in my PR. Something like
$readonly = isset($attribs['readonly']) && $attribs['readonly'];
would make more sense imho then.

yes, it is.

Do you want to adjust your PR or shall I update mine? Since I didn't change that part in my PR, you can do it as your own and get proper credits.

No problem. you do it to complete your PR. and i will close my PR and link to your PR.

Actually, looking at it again, the formfield will work with readonly=true (in fact, that's what we use in core) with my PR.
The only place you need the attribute['required'] to be set to 'required' is when you use JHtml::_('calendar') directly. We only use that in com_banners in the tracks view, but without disabled or readonly attributes.

Thus I think it will be better if you update your PR and also change title and test instructions on how to test this change.

I tested with #2531 pr and yes, it work with readonly="true" in forms. then with your fix, it work correctly.
one test & one question for directly use of JHtml::('calendar') with readonly attributes without patch my PR.
test: in file administrator/components/ombanners/views/tracks/tmpl/default.php line 52
change array('size' => 10, 'onchange' => "this.form.fireEvent('submit');this.form.submit()")
to : array('size' => 10, 'onchange' => "this.form.fireEvent('submit');this.form.submit()", 'readonly' => true)
now check track view of com_banners. Begin date is readonly. How it is possible when in calender function it check that $attribs['readonly'] == 'readonly'

Ha! That's indeed an interesting one
We're comparing a boolean value true to a string readonly which always evaluates true if we use ==. This is because non-empty strings are considered as true.

then if apply your pr, we do not need my pr

I think I found why it's done this way. The attributes are used directly as attributes for the HTML output of the field.
That means if you want valid HTML you need the attribute to be readonly="readonly". So we have in fact a bug, but a different one, because the comparision should probably be strict with === instead of ==

@mhehm Since PR #2531 is committed, do we still need yours?

After one month without further reply I am closing this, it can always be reopened if needed