[MAGNOLIA-2654] Can't render trees and lists with Safari 4.0 Created: 09/Mar/09  Updated: 23/Jan/13  Resolved: 22/Jun/09

Status: Closed
Project: Magnolia
Component/s: admininterface, gui
Affects Version/s: 4.0
Fix Version/s: 3.6.6, 4.0.2, 4.1.1

Type: Bug Priority: Blocker
Reporter: Christian Ringele Assignee: Magnolia International
Resolution: Fixed Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: HTML File Safari4Test.html    
Issue Links:
relation
is related to MAGNOLIA-2778 Google Chrome fails to render magnoli... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

In Safari 4.0 beta (Version 5528.16) no trees are rendered in the admin interface.
This is on all tabs (Configuration, DMS etc).



 Comments   
Comment by Philipp Bärfuss [ 23/Mar/09 ]

Lets wait and hope for the non-beta version

Comment by Magnolia International [ 10/Jun/09 ]

Confirmed with the recently release final version of Safari 4

Comment by Magnolia International [ 10/Jun/09 ]

from the users list - On 09.06.2009, at 15:48, Joshua Portway wrote:

The only serious looking errors I can see appearing in the Safari error console seem to be with some confusion about nested head and body elements - i suspect the html being downloaded for the tree view includes head elements and is maybe being directly added to the page, head-and-all ?

here's the console output :

messages.en.jsResource interpreted as other but transferred with MIME type application/x-javascript.
adminCentral.html:91Unmatched </head> encountered. Ignoring tag.
adminCentral.html:92Extra <body> encountered. Migrating attributes back to the original <body> element and ignoring the tag.
admin-all.cssResource interpreted as other but transferred with MIME type text/css.
theme.cssResource interpreted as other but transferred with MIME type text/css.
calendar-en.jsResource interpreted as other but transferred with MIME type application/x-javascript.
calendar-setup.jsResource interpreted as other but transferred with MIME type application/x-javascript.
website.html:4<title> is not allowed inside <body>. Moving <title> into the <head>.
website.html:4Unmatched </head> encountered. Ignoring tag.
website.html:4

Comment by Philipp Bärfuss [ 11/Jun/09 ]

No we don't add the html (head, ...). We use a iframe. But I have seen this wired messages in older version of Safari too.

Comment by Magnolia International [ 18/Jun/09 ]

Findings so far:

  • the issue most likely lies within the resize function of the tree js class
  • around line 300 of tree.js, we attempt to modify CSSStyleDeclaration instances ( cssClassObj.style.left=left; ) - this seems to be ignored by safari 4
Comment by Magnolia International [ 18/Jun/09 ]

Minimal testcase showing that the above actually works (or should) in s4.

Comment by Magnolia International [ 19/Jun/09 ]
  • the modification of style through CSSStyleDeclaration actually works, even in the context of the tree - just prooved by modifying the backroundColor property. Positioning issue ?
Comment by Magnolia International [ 19/Jun/09 ]

As it turns out, the real reason this is failing is because we set the value of the left style property to a numeric value without a unit such as px. Firefox shows the exact same problem if you render the page in standards-compliance mode (for instance by adding a valid doctype to the page)

The list pages also have the same problem.

Comment by Magnolia International [ 19/Jun/09 ]

Lists and trees now work with FF3, Safari 3 and 4 and Chrome - at least on my mac !
Leaving open: to be re-tested and validated on windows and IE. (should not cause any problem)

Generated at Mon Feb 12 03:38:48 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.