WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED CONFIGURATION CHANGED
18596
Google Docs do not compare in Safari (5874511)
https://bugs.webkit.org/show_bug.cgi?id=18596
Summary
Google Docs do not compare in Safari (5874511)
Kevin McCullough
Reported
2008-04-18 13:32:01 PDT
This bug was reported to me, but I have been unable to reproduce it and wanted to keep track of it and see if anyone else had experienced it. Steps To Reproduce: 1. Create a Googe Docs document. 2. Make sevral revsions over time. You can force this by saving between edits/entrie. 3. Share the doc with another GOOG account 4. Edit the doc from that other account, make sevral revisions as above. 5. From either account get into Revision History 6. Check two revisions and Compare Checked/
Attachments
Test that adds a <style> element to the head.
(542 bytes, text/plain)
2008-04-23 17:27 PDT
,
Kevin McCullough
no flags
Details
Test that adds a <style> element to the body.
(558 bytes, text/plain)
2008-04-23 17:27 PDT
,
Kevin McCullough
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Kevin McCullough
Comment 1
2008-04-18 13:36:54 PDT
related to
https://bugs.webkit.org/show_bug.cgi?id=18598
Kevin McCullough
Comment 2
2008-04-23 17:26:20 PDT
I believe what is going on is that Google Docs is adding a <style> tag to an element in the body of the document. This is not legal in HTML 4 and each browser handles it differently. Currently we copy any <style> tags into the head during parsing, but if they are added after parsing we will miss them. I believe this is what is happening. The simplest solution would be for Google Docs to add the <style> element to the head and not within the body. Also I found a workaround to this issue. To get to the Revision History you can either click on the document you wish to view, then choose the JS File menu, then click Revision History, then choose your revisions, or you can right-click on the document you wish to view, then choose Revisions, then choose the revisions you wish to compare. In the first set of steps the bug will happen, in the second it will not and the highlighting will happen correctly.
Kevin McCullough
Comment 3
2008-04-23 17:27:04 PDT
Created
attachment 20783
[details]
Test that adds a <style> element to the head.
Kevin McCullough
Comment 4
2008-04-23 17:27:24 PDT
Created
attachment 20784
[details]
Test that adds a <style> element to the body.
Ojan Vafai
Comment 5
2008-04-23 17:45:50 PDT
Why not fix this in Safari? While it may be illegal according to the spec and browsers may do different things, Safari is the only one that breaks here, right?
Dave Hyatt
Comment 6
2008-04-23 23:02:10 PDT
Yes, the bugs are filed and we plan to fix them, but the assumption is that you might want to work around the problem. Putting styles in the head will perform better even in browsers that support programmatic insertion of styles anywhere. Basically it's poor coding practice to put styles all over your body. If you don't care that's fine, but it's still sloppy coding to do it.
https://bugs.webkit.org/show_bug.cgi?id=5476
https://bugs.webkit.org/show_bug.cgi?id=5478
David Kilzer (:ddkilzer)
Comment 7
2008-04-24 09:12:01 PDT
See also:
https://bugs.webkit.org/show_bug.cgi?id=11397
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug