1527615 - <input type="date"> doesn't work in thunderbird

Status: RESOLVED FIXED

(Thunderbird :: General, enhancement)

Description

[Magnus Melin [:mkmelin]]

Attachment: tb-input-date.patch

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

Comment 1

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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

Comment 2

[Jonathan Kamens]

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.

Comment 3

[Jonathan Kamens]

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

Comment 4

[Geoff Lankow (:darktrojan)]

Attachment: 1527615-date-picker-1.diff

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.

Comment 5

[Magnus Melin [:mkmelin]]

Comment on attachment 9074391 [details] [diff] [review]
1527615-date-picker-1.diff

Review of attachment 9074391 [details] [diff] [review]:
-----------------------------------------------------------------

Great! Can you hook it up for the messagepane too? (My standard test case for these is chaning the start page)

Comment 6

[Geoff Lankow (:darktrojan)]

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.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/537896eeac1b
Hook up HTML date picker in content tabs; r=mkmelin

Comment 8

[Geoff Lankow (:darktrojan)]

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

Comment 9

[Jorg K (CEST = GMT+2)]

Comment on attachment 9074391 [details] [diff] [review]
1527615-date-picker-1.diff

Dependent on uplift of bug 1529205.

Comment 10

[Jonathan Kamens]

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.

Comment 11

[Jorg K (CEST = GMT+2)]

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

Comment 12

[Jorg K (CEST = GMT+2)]

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

Comment 13

[Jonathan Kamens]

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?

Comment 14

[Geoff Lankow (:darktrojan)]

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.

Comment 15

[Geoff Lankow (:darktrojan)]

Attachment: datepicker.xul

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.

Comment 16

[Jonathan Kamens]

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?

Comment 17

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 18

[Magnus Melin [:mkmelin]]

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.