Closed Bug 939619 Opened 8 years ago Closed 6 years ago

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

Categories

(Web Compatibility :: Desktop, defect)

Firefox 25
x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: arvinb, Unassigned)

References

Details

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

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.
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
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)
(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: → 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!!)
Duplicate of this bug: 1247917
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
Closed: 6 years ago
Resolution: --- → FIXED
Confirmed fixed in Server.app 5.1
Thanks Sean. Verifying based on Comment #18.
Status: RESOLVED → VERIFIED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.