[:Cww] Reporter
	Description • 10 years ago

Check out the screenshot. Chrome. When you hover, it looks like Chrome is trying to implement its own date picker? (Random guess, probably horribly wrong)

	[:Cww] Reporter
	Comment 1 • 10 years ago

Here's the screenshot when you click in the box.

	Will Kahn-Greene [:willkg] ET needinfo? me
	Comment 2 • 10 years ago

I have no idea how many people look at the dashboard with Chrome. We're planning to redo the dashboards, but we use this same date picker code across the codebase, so it'll be a problem with the new dashboards, too.

Putting it in this quarter to look into.

	Will Kahn-Greene [:willkg] ET needinfo? me
	Comment 3 • 10 years ago

Pushing this off to the next quarter.

	Will Kahn-Greene [:willkg] ET needinfo? me
	Comment 4 • 10 years ago

Making this a mentored bug.

There are datepickers on the front page dashboard. These don't seem to work right with Google Chrome. This bug covers figuring out what's wrong and fixing it.

This requires you to have Google Chrome installed and probably requires some expertise in CSS, HTML and JavaScript.

This is a mentored bug. If you're interested in working on it, comment here or ping willkg in #input on irc.mozilla.org.

	James McCoy
	Comment 5 • 10 years ago

The problem actually seems to be that Mozilla doesn't implement HTML5's type="date" attribute for input fields -- https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms/The_native_form_widgets#Date_and_time_picker

Chrome does, so it displays a date picker which is conflicting with the date picker that is being applied to the field (by jQuery?).

The possible fixes would be to a) detect whether the browser implements type="date" and disable the custom date picker (c.f., http://modernizr.com/docs/) or b) set type="text" and always use the custom date picker.

	Will Kahn-Greene [:willkg] ET needinfo? me
	Comment 6 • 10 years ago

Aha! That makes sense. Thank you, James!

Whoever wants to take this bug, I'm game for whatever you want to implement.

For option A, we're not using modernizr, but adding a check for type=date support shouldn't be hard to do.

For option B, that's pretty easy to do.

	Ruben Vereecken Assignee
	Comment 7 • 10 years ago

I'd like to take on this bug. Since you're giving me some wiggle room I'll do some own investigation first but I'll get back with an update as soon as I've got something.

	Will Kahn-Greene [:willkg] ET needinfo? me
	Comment 8 • 10 years ago

Assigning it to you. Feel free to look into it more and if you have any problems, let me know! Thank you!

	Ruben Vereecken Assignee
	Comment 9 • 10 years ago

I ended up with a third option: Disable the native date picker while keeping [type="date"] (I don't like messing with semantics unnecessarily). 

In the end I'd like to go for previously mentioned option A: detect browser support and only activate jQuery's date picker when it seems missing. This is best I felt for mobile browsers; I tested with Chrome Mobile on Android and I liked how it felt Androidish.

I then grep'd around fjord's codebase and noticed the check needed to be in several places. I'm now checking whether I want to have the code duplicated or add a global since there doesn't seem to be a way to `require` functionality from other files.

Either way, PR incoming soon.

	Ruben Vereecken Assignee
	Comment 10 • 10 years ago

PR #340 https://github.com/mozilla/fjord/pull/340

	Will Kahn-Greene [:willkg] ET needinfo? me
	Comment 11 • 10 years ago

Fjord javascript files are minimized and concatenated on a per-view basis. We haven't had a need for modularization/require stuff, yet.

	Will Kahn-Greene [:willkg] ET needinfo? me
	Comment 12 • 10 years ago

Landed in master: https://github.com/mozilla/fjord/commit/a2a491dcc731b03462edc776f99b01c240b64a0d

I'll push this later today.

Thank you, Ruben and James!

	Will Kahn-Greene [:willkg] ET needinfo? me
	Comment 13 • 10 years ago

Pushed to prod just now. Yay!