Closed
Bug 1337234
Opened 7 years ago
Closed 7 years ago
Add new webAPIs for XBL in child to get calendar terms
Categories
(Core :: DOM: Core & HTML, defect, P1)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox54 | --- | affected |
People
(Reporter: wesley_huang, Assigned: jessica)
References
(Blocks 1 open bug)
Details
(Whiteboard: [milestone5])
Attachments
(2 files)
6.78 KB,
patch
|
Details | Diff | Splinter Review | |
4.65 KB,
patch
|
Details | Diff | Splinter Review |
https://bugzilla.mozilla.org/show_bug.cgi?id=1287677#c42 Components.classes is for chrome code only, and the input box part for date/time inputs are in content side, implemented using XBL. Do you know if there is any other way I can access these utility functions? (e.g., we usually expose it in webidl and restrict it using [Func="IsChromeOrXBL"]).
Comment 1•7 years ago
|
||
:wchen, can you help us with this? I don't know how to expose webidl based on mozIntl.getDisplayNames for XBL.
Flags: needinfo?(wchen)
Comment 2•7 years ago
|
||
I can see many examples of XBL being able to use Components.classes (e.g. https://dxr.mozilla.org/mozilla-central/rev/f4f374622111022d41dd8d5eb9220624135c534a/toolkit/content/widgets/datetimepopup.xml#196) I don't understand the problem we are trying to solve. Why do we need another way to access the utility functions? Why does using WebIDL solve the problem?
Flags: needinfo?(wchen)
Updated•7 years ago
|
Priority: -- → P2
Assignee | ||
Comment 3•7 years ago
|
||
XBL code in child does not have privileges to access mozIMozIntl. After discussing with :smaug, one way to solve this is to expose ChromeOrXBL method in Window, so that XBL code in child can access it. We are not going to expose mozIMozIntl directly, but provide functions that map to mozIMozIntl functions. For example, for getLocaleInfo() (bug 1312053, not landed yet), we can expose it in Window as: partial interface Window { [Func="IsChromeOrXBL"] LocaleInfo getLocaleInfo(sequence<DOMString> locales); }; getDisplayNames()'s (bug 1287677) parameter and return value are more complicated, we may consider simplify a bit by accepting just one single key.
Assignee | ||
Updated•7 years ago
|
Summary: Add a new WebIDL for content process to get calendar terms → Add new webAPIs for XBL in child to get calendar terms
Assignee | ||
Comment 4•7 years ago
|
||
I can help with this. For input type=time input box, we need: - direction for locale: rtl/ltr (depends on bug 1312053) - 12/24hr format for locale
Assignee: nobody → jjong
Reporter | ||
Updated•7 years ago
|
Priority: P2 → P1
Whiteboard: [milestone5]
Assignee | ||
Comment 5•7 years ago
|
||
WIP based on bug 1312053. Exposes window.getLocaleInfo() to chrome or xbl.
Assignee | ||
Comment 6•7 years ago
|
||
Assignee | ||
Updated•7 years ago
|
Attachment #8837041 -
Attachment description: WIP → WIP for getLocaleInfo()
Assignee | ||
Comment 7•7 years ago
|
||
Maybe we should file separate bugs for each function needed, since we may add them one by one, in different time periods.
Assignee | ||
Updated•7 years ago
|
Reporter | ||
Comment 8•7 years ago
|
||
can we close this bug since all dependent bugs are done?
Assignee | ||
Comment 9•7 years ago
|
||
(In reply to Wesley Huang [:wesley_huang] (EPM) (NI me) from comment #8) > can we close this bug since all dependent bugs are done? Yes, I think I have all the APIs I need now. Will file new bugs if I need any other APIs.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•