1809911 - Santa Clara Water site does not render graph

Status: RESOLVED WONTFIX

(Web Compatibility :: Site Reports, defect)

Description

[Eric Rescorla (:ekr)]

STR:
Go to https://alert.valleywater.org/map?p=sensor&sid=4007&disc=f

Expected Results:
Graph renders

Actual Results:
Graph does not render.

Error console shows
XML Parsing Error: no root element found
Location: https://alertdata.valleywater.org/sensorData/4007/range/1/5/2023/1/12/2023?includeRating=true&skipZeroValues=true
Line Number 1, Column 1: 2023:1:1
Uncaught TypeError: self._showApiErrorMsg is not a function
getSensorData https://alert.valleywater.org/js/valleyWater.min.js?v=qF9Edl0IOwXS2T_tQaKNpnqVuEfbPgRJNxEv3Ew89d4:1
jQuery 4

This works in Beta but not Nightly. Also works in Chrome.

Comment 1

[Thomas Wisniewski [:twisniewski]]

Setting a breakpoint on that failing line with self._showApiErrorMsg, it looks like self isn't the object they expect it to be. It's the window object, but they seem to expect it to be the same as this.

Comment 2

[Thomas Wisniewski [:twisniewski]]

Hmm. Mozregession is telling me it's related to the ICU update in bug 1792775

Comment 3

[Dennis Schubert [:denschub]]

They're XHR'ing the chart's values based on the user-selected dates. In Chrome, they load

https://alertdata.valleywater.org/sensorData/4007/range/2023-01-01/2023-01-11?includeRating=true&skipZeroValues=true

but in Firefox, the same selected date range results in

https://alertdata.valleywater.org/sensorData/4007/range/1/1/2023/1/11/2023?includeRating=true&skipZeroValues=true

I also noticed that something else is off. The default select values are 05/01/2023 and 12/01/2023, so it looks like the site is expecting dd/mm/yyyy. However, opening the date picker in Firefox and Chrome Canary ends up showing me May 2023 and December 2023 respectively. Changing those dates to 01/01/2023 and 01/11/2023 (so, mm/dd/yyyy) makes it work. But even Chrome Canary then tries to load the URL with the slashes - so yeah, this indeed looks like another ICU regression.

ni?'ing myself to check the JS they're using to pre-populate the date fields, and the JS they're using to generate the URLs.

Comment 4

[André Bargull [:anba]]

This is likely the same issue as bug 1805995:

When opening the "valleyWater.min.js" file, search for toLocaleDateString("en-CA"). Before the ICU update, this was returning an ISO-style string like "1970-01-01". But that's no longer the case after the ICU resp. CLDR update.

Comment 5

[Jonathan Kew [:jfkthame]]

Looks like the site is doing something weird with dates.... when I load it here (from en-GB), it opens with the start/end dates showing "05/01/2023" and "12/01/2023", which would be the past week according to en-GB date formatting; but then it shows a message "Start must be before end date, and dates must not be in the future. Please check dates and try again."

Clicking the date-picker icons confirms that it is interpreting these dates -- which I guess must have been generated and filled in by the site's own JS -- as May 1st and Dec 1st, rather than Jan 5th and 12th.

Manually changing the date fields to en-US format seems to work in Firefox release (v108), and the graph appears, but in Nightly (110) it fails.

I see exactly the same in Chrome, fwiw: the date fields are confused by my en-GB locale; and once I work around that, the graph works in Chrome release but fails to render in Canary.

[edit: mid-aired with Dennis saying much the same thing]

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1792775

Comment 7

[Thomas Wisniewski [:twisniewski]]

The URL is built here:

      const t = '/sensorData/' + this._currentSensor.gageId + '/range/' + n.start + '/' + n.end + '?includeRating=true&skipZeroValues=true';
      // t = "/sensorData/4007/range/1/5/2023/1/12/2023?includeRating=true&skipZeroValues=true"
      $.ajax({
        url: valleyWaterSettings.ValleyWaterApiUrl + t,
        dataType: 'json',

So it's n, which is defined as:

    const n = this._getStartEndDates();

Which is using toLocaleDateString('en-CA'):

  _getStartEndDates: function () {
    const n = $('#sensorGraphEndDate').datepicker('getDate'),
    t = $('#sensorGraphStartDate').datepicker('getDate');
    return {
      start: t.toLocaleDateString('en-CA'),
      end: n.toLocaleDateString('en-CA'),
      startDate: t,
      endDate: n
    }
  },

Where the end results differ as expected:

Firefox: start = "1/12/2023",  end = "1/5/2023"
Chrome:  start = "2023-01-12", end = "2023-01-05"

So why are they using toLocaleDateString here? Not sure. Presumably they meant to use that function for what they render to the user, but ended up also using it to generate the URL by accident.

Comment 8

[Dennis Schubert [:denschub]]

Well, that's good to know. And most likely a no-op for us then - this will also break in Chrome Stable on Feb 7, which is earlier than our 110 release on Feb 14. Since Google didn't backout the ICU update so far, I don't think they will anytime soon.

I'll send them an email to give them a heads-up about this breaking soon...

Comment 9

[Thomas Wisniewski [:twisniewski]]

Ah, yes, they're using _getStartEndDates to render the dates elsewhere in the same file, so this is almost certainly just them not realizing they were sharing code incorrectly. If they want to fix this, they can just change that line to something like this:

      const start = n.startDate.toISOString().split("T")[0];
      const end = n.endDate.toISOString().split("T")[0];
      const t = '/sensorData/' + this._currentSensor.gageId + '/range/' + start + '/' + end + '?includeRating=true&skipZeroValues=true';

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1792775

Comment 11

[Dennis Schubert [:denschub]]

This is now also broken in Chrome Stable, since 109 is now released.

I sent them an email to [e-mail], which they mention on their site. I'll update this bug if I hear back from them, but since this is now also broken in Chrome, I don't think we need to do anything here. This needs to be addressed by their webdev team.

Comment 12

[André Bargull [:anba]]

We'll revert the date-time format in bug 1818103, because this is a more wide-spread problem.

Comment 13

[Dennis Schubert [:denschub]]

This is still broken in Chrome and Firefox, but there's nothing left to do for us here, as this isn't a WebCompat bug per se. Let's close this.