Closed Bug 1162492 Opened 4 years ago Closed 2 years ago

FF38esr: Oracle Calendar stopped working

Categories

(Web Compatibility :: Desktop, defect, P3)

Firefox 38
defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: mozilla, Unassigned)

References

Details

(Keywords: site-compat, Whiteboard: [country-us] [needscontact])

Attachments

(1 file)

45.24 KB, application/zip
Details
Attached file 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).
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?
Blocks: 779723
Flags: needinfo?(dirkjan)
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?
Flags: needinfo?(dirkjan) → needinfo?(kdubost)
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.
Flags: needinfo?(kdubost)
Whiteboard: [country-us] [needcontact]
Component: General → Desktop
Product: Firefox → Tech Evangelism
Version: 38 Branch → Firefox 38
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?
Flags: needinfo?(annevk)
So does this page also break in Chrome? I don't know where RadioNodeList originates from.
Flags: needinfo?(annevk)
From reading the code and poking Chrome's implementation I'm pretty sure it does, but reporter will have to verify.
Flags: needinfo?(mozilla)
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).
Flags: needinfo?(mozilla)
That explains things, thank you.
Whiteboard: [country-us] [needcontact] → [country-us] [needscontact]
Ignaz, assuming you still have access to an Oracle calendar, does this issue still reproduce in Firefox?
Flags: needinfo?(mozilla)
Priority: -- → P3
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?
Flags: needinfo?(mozilla) → needinfo?(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.
Flags: needinfo?(patric.busanny) → needinfo?(mozilla)
OK, thanks for checking.
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(mozilla)
Resolution: --- → INCOMPLETE
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.