1162492 - FF38esr: Oracle Calendar stopped working

Status: RESOLVED INCOMPLETE

(Web Compatibility :: Site Reports, defect, P3)

Description

[Ignaz Forster]

Attachment: Example page

With the update from Firefox 31esr to Firefox 38esr the Oracle Calendar 10.1.2 web frontend stopped working: It's not possible to create new calendar entries any more.

Tracing back it seems the issue was introduced in Firefox 33 (Firefox 32 is still working).

Steps to reproduce:
* Extract the contents of the attached "NeuerTermin.zip"
* Open "Neuer Termin.html"
* Click on "Erstellen" button (in the upper or lower right corner)

Actual result:
* Nothing happens

Expected result:
You should see Firefox's "file not found" page (as this example doesn't contain the next page).

Comment 1

[Ignaz Forster]

There seems to be a naming conflict between the support of https://developer.mozilla.org/en-US/docs/Web/API/RadioNodeList/value and line 448 in "Neuer Termin.html". Both are using "value" on a RadioNodeList, but with the introduction of the attribute as part of a standard the attribute doesn't behave as it used to do. I guess there's nothing that can be done here, is it?

Comment 2

[Dirkjan Ochtman (:djc)]

I don't think there's anything we can do from a technical perspective, no. They seem to be using the value attribute on a NodeList that doesn't contain any radio elements, so the value set by the code will not be persisted as they expect.

On the other hand, perhaps we could do something from the evangelism side. Karl, do we have anything going with Oracle?

Comment 3

[Karl Dubost💡 :karlcow]

There are bug 508563 and bug 1154485 but we do not have an active contact currently with Oracle.
I'll try to check next week.

Comment 4

[Hallvord R. M. Steen [:hallvors]]

I confirm that document.entryedit_form.buttonlayer returns a RadioNodeList in Firefox, Chrome and IE. It's a confusing name though - it does *not* include only type="radio", in this particular case the inputs are type=hidden. The spec is sort of inconsistent here - why have a collection.value that's only relevant (and only in fact working) for type=radio but include all types in the collection?

As I no longer have access to older IEs I don't know exactly what this page expects. Either I guess the form.elementname syntax is expected to return one single element whose .value gets set (most likely) or they rely on the fact that the collection did not have a magic .value property before, set .value to 'on' on the collection itself and later run a script that processes collection.value.

It seems to be the latter:

function checkSubmission() {
	if (checkChildWinOpen()) {
		return false;
	}
	if (document.entryedit_form.buttonlayer.value == 'on') {
		updateIsChildWinOpenVar(true);
		return true;
	}

So - does this spec innovation make enough sense to warrant breaking a page? Couldn't we have a RadioNodeList with .value and only type=radio (and type=checkbox?) in it, and a separate FormElementsList collection with no .value?

Comment 5

[Anne (:annevk)]

So does this page also break in Chrome? I don't know where RadioNodeList originates from.

Comment 6

[Hallvord R. M. Steen [:hallvors]]

From reading the code and poking Chrome's implementation I'm pretty sure it does, but reporter will have to verify.

Comment 7

[Ignaz Forster]

I have tested with Google Chrome 48.0.2564.109 and was surprised to see that the site is working there. However this is not because Chrome behaves differently, but obviously because Chrome gets another version of the website.

When using Chrome to view the Firefox version attached to this ticket, Chrome also breaks (it ignores setting document.entryedit_form.buttonlayer.value like Firefox does, though I didn't check for eventual further errors).

Comment 8

[Hallvord R. M. Steen [:hallvors]]

That explains things, thank you.

Comment 9

[Mike Taylor [:miketaylr]]

Ignaz, assuming you still have access to an Oracle calendar, does this issue still reproduce in Firefox?

Comment 10

[Ignaz Forster]

I'm not working for the affected organization any more, so I've CC'd a former colleague of mine.

Patric, is there still access to the old Oracle Calendar web frontend to retest this bug?

Comment 11

[Patric Busanny]

Our calendar has been migrated to another system.
I don't have access to the Oracle Calendar anymore.
Issue can't be retested.

Bug can be closed.
Thank you.

Comment 12

[Mike Taylor [:miketaylr]]

OK, thanks for checking.