WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
97318
DateTimeNumericFieldElement should use Localizer functions.
https://bugs.webkit.org/show_bug.cgi?id=97318
Summary
DateTimeNumericFieldElement should use Localizer functions.
Kent Tamura
Reported
2012-09-21 03:00:56 PDT
DateTimeNumericFieldElement should use Localizer functions. In the result of fast/forms/time-multiple-fields/time-multiple-fields-localization.html, "ar" locale doesn't use native digits at all.
Attachments
Patch
(6.72 KB, patch)
2012-09-27 01:39 PDT
,
Kent Tamura
no flags
Details
Formatted Diff
Diff
Patch 2
(12.96 KB, patch)
2012-09-27 03:58 PDT
,
Kent Tamura
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Kent Tamura
Comment 1
2012-09-21 07:55:59 PDT
Passing a Localizer for the host <input> to DateTimeNumericFieldElement is troublesome. We had better introduce Element::computeInheritedLanguageOverShadowBoundary() or something.
Kent Tamura
Comment 2
2012-09-27 01:39:05 PDT
Created
attachment 165950
[details]
Patch
yosin
Comment 3
2012-09-27 01:45:18 PDT
Comment on
attachment 165950
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=165950&action=review
> Source/WebCore/html/shadow/DateTimeNumericFieldElement.cpp:116 > + Element* host = shadowHost();
I think it is better to have a new function in FieldOwner interface, e.g. FieldOwner::localizer(). Implementation of DateTimeEditElement localizer() calls DateTimeEditElement::EditControlOwner::localizer(). We know DateTimeFieldElement always in shadow tree, but it is better to reduce number of assumptions.
yosin
Comment 4
2012-09-27 01:49:10 PDT
Comment on
attachment 165950
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=165950&action=review
>> Source/WebCore/html/shadow/DateTimeNumericFieldElement.cpp:116 >> + Element* host = shadowHost(); > > I think it is better to have a new function in FieldOwner interface, e.g. FieldOwner::localizer(). > Implementation of DateTimeEditElement localizer() calls DateTimeEditElement::EditControlOwner::localizer(). > > We know DateTimeFieldElement always in shadow tree, but it is better to reduce number of assumptions.
Is it better to have DateTimeEditOwner::localizeNumber() API? We don't need to have full Localizer in DateTimeNumericFieldElement. Also, we may need to rename "Localizer" sometimes in future. So, reducing number of reference to Localizer will help us.
Kent Tamura
Comment 5
2012-09-27 03:58:32 PDT
Created
attachment 165971
[details]
Patch 2 Add callbacks
Kent Tamura
Comment 6
2012-09-27 04:06:24 PDT
(In reply to
comment #3
)
> I think it is better to have a new function in FieldOwner interface, e.g. FieldOwner::localizer(). > Implementation of DateTimeEditElement localizer() calls DateTimeEditElement::EditControlOwner::localizer().
I wanted to avoid it (See
Comment #1
) because we need to check nullness of m_fieldOwner and m_editControlOwner and to return fallback Localizer. Using locale identifier strings instead of Localizer objects is simpler (Patch 2).
> Is it better to have DateTimeEditOwner::localizeNumber() API?
I don't think so. We'll need other Localizer functions in the future.
yosin
Comment 7
2012-09-27 18:19:21 PDT
(In reply to
comment #6
)
> (In reply to
comment #3
) > > I think it is better to have a new function in FieldOwner interface, e.g. FieldOwner::localizer(). > > Implementation of DateTimeEditElement localizer() calls DateTimeEditElement::EditControlOwner::localizer(). > > I wanted to avoid it (See
Comment #1
) because we need to check nullness of m_fieldOwner and m_editControlOwner and to return fallback Localizer. > Using locale identifier strings instead of Localizer objects is simpler (Patch 2). > > > > Is it better to have DateTimeEditOwner::localizeNumber() API? > > I don't think so. We'll need other Localizer functions in the future.
ACK
Hajime Morrita
Comment 8
2012-09-27 18:24:27 PDT
Comment on
attachment 165971
[details]
Patch 2 View in context:
https://bugs.webkit.org/attachment.cgi?id=165971&action=review
> Source/WebCore/html/shadow/DateTimeNumericFieldElement.h:75 > + Localizer& localizer() const;
Can the return value be const?
Kent Tamura
Comment 9
2012-09-27 18:32:32 PDT
Comment on
attachment 165971
[details]
Patch 2 View in context:
https://bugs.webkit.org/attachment.cgi?id=165971&action=review
>> Source/WebCore/html/shadow/DateTimeNumericFieldElement.h:75 >> + Localizer& localizer() const; > > Can the return value be const?
It can't. Localizer member functions are not const because of lazy initialization, and we need to call them.
yosin
Comment 10
2012-09-27 19:09:10 PDT
I think it is better that EditControlOwner returns Localizer instead of locale identifier to improve modulelaity and to hide how to get Localizer in DateTimeFieldElement.
WebKit Review Bot
Comment 11
2012-09-27 19:35:48 PDT
Comment on
attachment 165971
[details]
Patch 2 Clearing flags on attachment: 165971 Committed
r129832
: <
http://trac.webkit.org/changeset/129832
>
WebKit Review Bot
Comment 12
2012-09-27 19:35:51 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug