Bug 97318

Summary: DateTimeNumericFieldElement should use Localizer functions.
Product: WebKit Reporter: Kent Tamura <tkent>
Component: FormsAssignee: Kent Tamura <tkent>
Status: RESOLVED FIXED    
Severity: Normal CC: keishi, mifenton, morrita, webkit.review.bot, yosin
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 96351    
Attachments:
Description Flags
Patch
none
Patch 2 none

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
Patch 2 (12.96 KB, patch)
2012-09-27 03:58 PDT, Kent Tamura
no flags
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
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.