Closed Bug 1012965 Opened 10 years ago Closed 10 years ago

Date picker looks broken in chrome

Categories

(Input Graveyard :: Dashboard, defect, P3)

x86
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: cww, Assigned: rubenvereecken, Mentored)

Details

Attachments

(2 files)

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)
Here's the screenshot when you click in the box.
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.
Priority: -- → P3
Whiteboard: u=user c=dashboard p= s=input.2014q2
Pushing this off to the next quarter.
Whiteboard: u=user c=dashboard p= s=input.2014q2 → u=user c=dashboard p= s=input.2014q3
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.
Mentor: willkg
Whiteboard: u=user c=dashboard p= s=input.2014q3
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.
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.
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.
Assigning it to you. Feel free to look into it more and if you have any problems, let me know! Thank you!
Assignee: nobody → rubenvereecken
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.
Fjord javascript files are minimized and concatenated on a per-view basis. We haven't had a need for modularization/require stuff, yet.
Landed in master: https://github.com/mozilla/fjord/commit/a2a491dcc731b03462edc776f99b01c240b64a0d I'll push this later today. Thank you, Ruben and James!
Pushed to prod just now. Yay!
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Product: Input → Input Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: