I was going to check if we can just use <input type="date"> for some things.

It's not currently working.

I added the initialization for the DateTimePickerParent, but then I get
JavaScript error: resource://gre/modules/DateTimePickerParent.jsm, line 114: TypeError: aBrowser.ownerGlobal.gBrowser is undefined

Sounds like this bug should move to m-c so it can be made independent of gBrowser, given this is in toolkit not browser/

Sounds like this bug should move to m-c so it can be made independent of gBrowser, given this is in toolkit not browser/

<input type="date"> and <input type="time"> work fine in Firefox, so I'm not sure why this would be a m-c bug rather than a c-c bug.

I was led to believe this would be fixed for TB68? Yes? Please?

Bug 1529205 is landing now. This hooks Thunderbird up to it, at least for the content tab browser. The fix for any other browser element (ie. in extensions) is the same.

Can you hook it up for the messagepane too?

I forgot that we sometimes load regular content there.

It's complicated. I'll add the <stack> around that <browser>, but we currently have code that prevents any clicking on an <input> in the messagepane from working as one would expect. Follow-up bug, I think.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/537896eeac1b
Hook up HTML date picker in content tabs; r=mkmelin

Tracking as I don't yet have permission to land the m-c part on m-b.

I'm unclear on exactly what the problem and fix are here, so forgive me if some of these questions are off-point...

I would like to be able to use the HTML date-picker and time-picker in my add-on's own dialog windows and in toolbar palette items in the composition window toolbar. Will the fixes so far included in this issue enable me to do both of those?

Also, is this fix going to be in TB68 or just TB69?

Thanks.

By hook or be crook, I'll ship the fix in TB 68 beta 4.

TB 68 beta 4:
https://hg.mozilla.org/releases/comm-beta/rev/080358755365f241ef3f327683bed5ff2a6bbd27

When I call window.openDialog on this XUL file in today's daily build, none of the input fields specified in it work:

<?xml version="1.0"?>

<?xml-stylesheet href="chrome://global/skin/global.css" type="text/css"?>
<?xml-stylesheet href="chrome://messenger/content/bindings.css" type="text/css"?>

<window xmlns:html="http://www.w3.org/1999/xhtml"
        xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
  <vbox>
    <html:input type="date"/>
    <html:input type="time"/>
    <html:input type="datetime-local"/>
  </vbox>
</window>

Am I doing something wrong?

Given the changes needed to get to this point, I don't think it's working outside of a document in a <browser>. But the pieces exist so it should be possible to stitch them together somehow. I'll try to figure it out.

Here's a minimal example that connects the built-in picker pop-up to a button. I haven't been able to use the actual HTML input element, but I think for most cases this should suffice.

1. I have no idea from looking at your example how to actually get the value the user has selected.

2. I am extremely uncomfortable putting this level of hackery into my add-on code. It's gross and kludgy and having read the code over several times I still have no idea what magic it is or how it works.

Is this how things are going to be forever, or are we actually going to fix TB in some later release so that add-ons can simply, cleanly use html:input type="date" etc. in their XUL?

The cleaner solution in the future would be to not use XUL. It may be working for now, but we need to be careful for the amount of workarounds and fixes we make available. We actually want add-on authors to migrate to MailExtensions, and if we keep on fixing XUL then this will never happen.

In this case using html will not work per se, that's the bug: the way these widgets are implemented they do not fully work when used in an html document that is not inside in a browser... Geoff's workaround in comment 15 is just adding the expectations the widget has for this particular case.

This is not an isolated case. I think the real fix for this horde of issues will be having much of our chrome running essentially in a <browser>, but that's of course not that easily doable.