OS X Mavericks Server 3.0 webcal doesn't work in Firefox

VERIFIED FIXED

Status

Tech Evangelism
Desktop
VERIFIED FIXED
4 years ago
2 years ago

People

(Reporter: arvinb, Unassigned)

Tracking

Firefox 25
x86
Mac OS X

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [js] [country-all] [sitewait])

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131112160018

Steps to reproduce:

Bring up web calendar using Firefox on either Windows XP or OS X Mavericks. I am hosting my own OS X server and others seem to be having the same issue.

Thread: https://discussions.apple.com/index.jspa?showpreview=true

Other browsers are not having an issue. Tested with Safari and Internet Explorer 11.


Actual results:

The calendar webcal site does not load all calendars.


Expected results:

All calendars should load and the site be usable.
Comment hidden (me-too)
Comment hidden (obsolete)

Comment 3

3 years ago
https://discussions.apple.com/thread/5528383

>I'm sure it is a bug in OS X server, because all Firefox versions on all platforms stopped to be working with the Mavericks update.
Component: Untriaged → Desktop
Product: Firefox → Tech Evangelism
Summary: FF Browser not working with OS X Server 3.0 webcal → OS X Mavericks Server 3.0 webcal doesn't work in Firefox
Version: 25 Branch → Firefox 25
Comment hidden (obsolete)
Comment hidden (obsolete)
Thank you!

The JS method getEventsForDateRange() should get called at some point. But when the script gets here:

this.mCalendars.each(function(cal) {
	request = cal.getEventsForDateRange(inStartDate, inEndDate, calendarResultsCallback);

For some reason this.mCalendars is an empty list in Firefox. I'll have to dig a bit more to figure out why.
Element.childrenWithNodeName(supported, 'comp').each(function(compNode) {
	if (Element.firstNodeValue(compNode.attributes.getNamedItem('name')) == 'VEVENT')
		supportsEvents = true;
	}.bind(this));

meets XML markup

<comp name="VEVENT"/>

The problem is that Element.firstNodeValue(compNode.attributes.getNamedItem('name')) returns an empty string because firstNodeValue looks for 'firstChild' on an attribute node. Seems Gecko doesn't support that (anymore?)

I think there was some discussion fairly recently (within last two years?) about removing attribute node's firstChild from the DOM standard. There's no trace of a firstChild property here: https://dom.spec.whatwg.org/#attr . The calendar javascript should just read .value instead of .firstChild.nodeValue and it would work fine.

Potentially related: bug 566416. I haven't found a bug that says "remove attribute node firstChild support" - per that bug it sounds like we used to have it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(arvinb)

Comment 8

3 years ago
(In reply to Hallvord R. M. Steen from comment #7)
> Potentially related: bug 566416. I haven't found a bug that says "remove
> attribute node firstChild support"
bug 737122. Do you have a way of contacting the apple devs?
(In reply to Nickolay_Ponomarev from comment #8)

> bug 737122.

Indeed. Fixing that bug (and aligning with the now simplified DOM standard) broke this site.

> Do you have a way of contacting the apple devs?

We'll do our best.
I've asked a former colleague of mine who now works at Apple whether he can pass on some information to the right team. (I hope it's easy to figure out who works on what inside Apple ;) )
Assignee: nobody → hsteen
Whiteboard: [js] [country-all] [sitewait]
If this is an internally deployed application--I don't know if it's even possible to get updates deployed to versions in the wild.
See Also: → bug 737122
Assignee: hsteen → nobody
I just wanted to note that this problem still exists with the newest versions of OS X Server.app (5.0.15), and Firefox (42.0).  Chromium has the same problem.  Safari and IE can render the page fine.  I personally have no idea if it's a bug in the web page/server or in the web browser (or both).

I've filed a bug with Apple too <rdar://23534377>, to investigate their side of things.  Alas, their bug database is not publicly viewable. :(
Sean, it is a bug in the web page so Apple needs to fix it ;)
(And thanks a lot for reporting the issue to them!!)

Updated

2 years ago
Duplicate of this bug: 1247917

Comment 16

2 years ago
Apparently Apple is going to fix this issue with OS X Server 5.1 (installed on OS X 10.11.4).

There is no more issue with Firefox 42.0 and OS X Server 5.0.25 (5.1 Beta 5) installed on OS X 10.11.4 Beta (15E61b).
Given that it's working in 5.0.25 (5.1 Beta 5), let's close this as fixed.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Confirmed fixed in Server.app 5.1
Thanks Sean. Verifying based on Comment #18.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.