Closed Bug 1036987 Opened 10 years ago Closed 6 years ago

XML Parsing error: not well-formed when trying to reply to an email through the Gmail web interface on Firefox OS

Categories

(Web Compatibility :: Site Reports, defect, P5)

Product:
Web Compatibility
Component:
Site Reports
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: ehsan.akhgari, Assigned: karlcow)

References

(Depends on 1 open bug,
URL
)

Details

(Whiteboard: [country-all] [http] [sitewait] [xhtml] [platform-rel-Google] [platform-rel-Gmail])

Attachments

(1 file)

gmail-issues-gecko.jpg
474.32 KB, image/jpeg
Details 
STR:

1. Log in to the Gmail web interface on Firefox OS (I tried on a Flame).
2. Click on an email, and hit reply.

It seems like Gmail is serving a malformed XML document as XHTML, which Gecko parses as XML but other UAs won't.
Interesting it means that gmail is sending a XHTML mime type: application/xhtml+xml.
It would be interesting to check this.

Ehsan, 
1. does it happen with every emails?
2. are you connecting through wifi?
   (asking because on 3g some OEMs have bad habits of changing the headers)


Todo: maybe me?
We would need a sample of the markup and a sample of the http headers. I wonder if the proxy settings have been fixed in Firefox OS.
Assignee: english-us → nobody
URL: http://mail.google.com/
Component: English US → Mobile
Flags: needinfo?(ehsan)
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
Whiteboard: [country-all] [http] [notcontactready]
(In reply to Karl Dubost :karlcow from comment #1)
> Ehsan, 
> 1. does it happen with every emails?

Yes, I tested a few emails, and it happened with every one.

> 2. are you connecting through wifi?
>    (asking because on 3g some OEMs have bad habits of changing the headers)

I tested using the Toronto office Wifi.

> Todo: maybe me?
> We would need a sample of the markup and a sample of the http headers. I
> wonder if the proxy settings have been fixed in Firefox OS.

I tried changing the UA string on desktop, and the Gmail you get that way doesn't seem to have this issue.
Flags: needinfo?(ehsan)
I confirm that GMail sends 
Content-Type:"application/xhtml+xml; charset=UTF-8"

I can't reproduce this issue though. Is there anything particular (HTML formatting? Charset?) about the E-mails you were replying to?
Flags: needinfo?(ehsan)
Not that I know of.
Flags: needinfo?(ehsan)
So someone else had the same issue on 2.1 
Bug 668275#c28

> The ui is almost ok now with b2g 2.1 but I can't reply nor forward any message.
> See this http://imgur.com/mTS9Gra
I confirm this bug both when replying and forwarding emails
The screenshot in comment #5 shows half of the XML parse error. Can someone with this problem tell me what the rest of the error message says?
If I try opening  https://mail.google.com/mail/mu/ I got a forbidden message, error 403
You can find the almost complete error here http://videobam.com/wKXYj(In reply to Hallvord R. M. Steen from comment #7)
> The screenshot in comment #5 shows half of the XML parse error. Can someone
> with this problem tell me what the rest of the error message says?

You can find the almost complete error here http://videobam.com/wKXYj
Thanks for the efforts ;) Unfortunately the XML error isn't very user-friendly, it seems the phone doesn't let you scroll all the way to where it actually quotes the *broken* markup..

The version I get on Firefox OS is a pretty plain one - simple HTML, while reading mail it generally shows one message at a time and even splits long messages across pages - so this version is clearly meant for quite poor feature phones. The path name starts with /mail/u/0/x/ . Is this the version you others are seeing too?
(In reply to Hallvord R. M. Steen from comment #10)
> Thanks for the efforts ;) Unfortunately the XML error isn't very
> user-friendly, it seems the phone doesn't let you scroll all the way to
> where it actually quotes the *broken* markup..
> 
> The version I get on Firefox OS is a pretty plain one - simple HTML, while
> reading mail it generally shows one message at a time and even splits long
> messages across pages - so this version is clearly meant for quite poor
> feature phones. The path name starts with /mail/u/0/x/ . Is this the version
> you others are seeing too?

Is this the broken point ? http://imgur.com/lM28xDU
Or is it the end of the line ? I can scroll it all
(In reply to comment #10)
> Thanks for the efforts ;) Unfortunately the XML error isn't very user-friendly,
> it seems the phone doesn't let you scroll all the way to where it actually
> quotes the *broken* markup..

Well, it almost doesn't really matter what the broken markup is.  Unless on the Gmail server side they are generating their markup using a conforming XML processing library and are converting the markups in HTML emails to valid XML (both of which are *extremely* unlikely) we should ask them to stop serving us XHTML content, because we do treat XHTML as valid XML and if you get a tiny detail wrong, the XML parser barfs at you as we can see here.

> The version I get on Firefox OS is a pretty plain one - simple HTML, while
> reading mail it generally shows one message at a time and even splits long
> messages across pages - so this version is clearly meant for quite poor feature
> phones. The path name starts with /mail/u/0/x/ . Is this the version you others
> are seeing too?

Yes.
(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #12)

> Well, it almost doesn't really matter what the broken markup is.

You're right, it doesn't - just curious why you all see it and I don't.. From the screenshot I think it only happens if you have more than one *sender* address configured in GMail..

Bingo! I've added an alternate "Send as" address, and I can reproduce the broken XHTML bug now.
Severity: normal → major
Priority: -- → P1
Whiteboard: [country-all] [http] [notcontactready] → [country-all] [http] [contactready] [xhtml]
Bug 1020058 might contain another STR, can you please check?  Thanks!
Depends on: 1044332
Assignee: nobody → kdubost
Status: NEW → ASSIGNED
I think Android is affected here too as per bug 1064208. I see an XML error too on Nightly (09/08).
Maybe in case of xhtml+xml content type we could fallback to the xHTML parser if the XML one fails.
(In reply to Rémy Hubscher (:natim) from comment #21)
> Maybe in case of xhtml+xml content type we could fallback to the xHTML
> parser if the XML one fails.

We did this at Opera, emitting an message to the error console as well. See https://dev.opera.com/blog/no-more-xml-parsing-failed-errors/.
Related to Mike's comment: Bug 941241
See Also: → 941241
Personally, I hope iOS can remove the automatic fallback to text/html too.
(In reply to Yuhong Bao from comment #24)
> Personally, I hope iOS can remove the automatic fallback to text/html too.

That's extremely unlikely. Opera fought this battle for years, eventually we had to relax parsing of content sent as application/xhtml+xml.

Draconian tech lost on the web. Permissive (but well-specified) parsing won. 

And you know, if we had started out with strictness and XML requirements - would the web even have taken off? Didn't it expand *because* editing and publishing was so easy? What if I told you humans are designed to make little mistakes and computers are designed to handle them? ;)

(This discussion has gone on for so long I don't plan to continue it here..)
(In reply to Hallvord R. M. Steen from comment #25)
> (In reply to Yuhong Bao from comment #24)
> > Personally, I hope iOS can remove the automatic fallback to text/html too.
> 
> That's extremely unlikely. Opera fought this battle for years, eventually we
> had to relax parsing of content sent as application/xhtml+xml.
> 
> Draconian tech lost on the web. Permissive (but well-specified) parsing won. 
> 
> And you know, if we had started out with strictness and XML requirements -
> would the web even have taken off? Didn't it expand *because* editing and
> publishing was so easy? What if I told you humans are designed to make
> little mistakes and computers are designed to handle them? ;)
> 
> (This discussion has gone on for so long I don't plan to continue it here..)

The point is that I don't think mobile content designed for iOS or Android tend to use application/xhtml+xml. And I am removing the automatic fallback to text/html only.
(In reply to Hallvord R. M. Steen from comment #25)
> (In reply to Yuhong Bao from comment #24)
> > Personally, I hope iOS can remove the automatic fallback to text/html too.
> 
> That's extremely unlikely. Opera fought this battle for years, eventually we
> had to relax parsing of content sent as application/xhtml+xml.
> 
> Draconian tech lost on the web. Permissive (but well-specified) parsing won. 
> 
> And you know, if we had started out with strictness and XML requirements -
> would the web even have taken off? Didn't it expand *because* editing and
> publishing was so easy? What if I told you humans are designed to make
> little mistakes and computers are designed to handle them? ;)
> 
> (This discussion has gone on for so long I don't plan to continue it here..)

And if Opera Presto wasn't dead, I'd talk about how most of the broken ASP.NET sites has since been upgraded, especially with Server 2003 support ending.
(In reply to Yuhong Bao from comment #27)
> And if Opera Presto wasn't dead, I'd talk about how most of the broken
> ASP.NET sites has since been upgraded, especially with Server 2003 support
> ending.

So I was interested by this claim, and I dived into the old Opera archive of XHTML parsing bugs for ASP.Net sites. It falls in 4 categories:

* The user agent sniffing has been fixed (text/html). The server has been upgraded. Example:
   X-AspNet-Version: 2.0.50727
   X-Powered-By: ASP.NET
   Server: Microsoft-IIS/7.5

* The user agent sniffing has been fixed (text/html). The server has NOT been upgraded. Example:
   X-AspNet-Version: 2.0.50727
   X-Powered-By: ASP.NET
   Server: Microsoft-IIS/6.0

* The URI or the site doesn't exist anymore.

* The URI is being redirected to a different URI.


http://www.otsukare.info/2011/03/03/wrong-to-be-right-with-xhtml
https://dev.opera.com/blog/improving-interoperability-the-story-of-a-bug/

I haven't found a Web site which still had the issue in **our limited collection**. That said it is consistent with one of my Web Compatibility axioms. Wait long enough and any Web compatibility bugs will solve by itself: rot linking, rusty web, throwable sites, change of technology.


It would be an interesting survey. Also to remember that in the past the issue was happening only for Presto as Firefox was being sent a… text/html.
(In reply to Karl Dubost :karlcow from comment #28)
> (In reply to Yuhong Bao from comment #27)
> > And if Opera Presto wasn't dead, I'd talk about how most of the broken
> > ASP.NET sites has since been upgraded, especially with Server 2003 support
> > ending.
> 
> So I was interested by this claim, and I dived into the old Opera archive of
> XHTML parsing bugs for ASP.Net sites. It falls in 4 categories:
> 
> * The user agent sniffing has been fixed (text/html). The server has been
> upgraded. Example:
>    X-AspNet-Version: 2.0.50727
>    X-Powered-By: ASP.NET
>    Server: Microsoft-IIS/7.5
> 
> * The user agent sniffing has been fixed (text/html). The server has NOT
> been upgraded. Example:
>    X-AspNet-Version: 2.0.50727
>    X-Powered-By: ASP.NET
>    Server: Microsoft-IIS/6.0
> 
> * The URI or the site doesn't exist anymore.
> 
> * The URI is being redirected to a different URI.
> 
> 
> http://www.otsukare.info/2011/03/03/wrong-to-be-right-with-xhtml
> https://dev.opera.com/blog/improving-interoperability-the-story-of-a-bug/
> 
> I haven't found a Web site which still had the issue in **our limited
> collection**. That said it is consistent with one of my Web Compatibility
> axioms. Wait long enough and any Web compatibility bugs will solve by
> itself: rot linking, rusty web, throwable sites, change of technology.

It also helps that enterprises tends to deploy what is pushed out on Windows Update in time too.
Just a note that while send/reply works in the gmail mobile interface for me today (on recent nightly FxOS build), the "search" function has this same XML error currently. I guess bug 1044332 is the fix but that doesn't seem to be getting much attention. Any suggestions here? Are there any alternatives?

STR: 
1. Navigate to gmail on a Firefox OS device (or change user agent in desktop firefox)
2. Click the magnify glass icon to start a search. 

Currently this results in an error like:

XML Parsing Error: not well-formed
Location: https://mail.google.com/mail/u/0/x/xi6mw76egjqt-/?&v=srch
Line Number 6, Column 38:

for(i=0;i<searchButtonElements.length;i++)
-------------------------------------^

(source truncated for sanity)


Affected versions:
- Nightly (3.0) FxOS build 
- Desktop Firefox (if you change the UA string to something like: "Mozilla/5.0 (Mobile; rv:18.0) Gecko/18.0 Firefox/18.0")
> I guess bug 1044332 is the fix but that doesn't seem to be getting much attention. Any suggestions here? Are there any alternatives?

It is not a good idea, XSS attack protection being a good reason why.
[Blocking Requested - why for this release]:
Broken Gmail is a blocker to using this as a dogfood device.
blocking-b2g: --- → spark?
triage:
removing nomination since it's a partner issue, and according to comment 0, this is an error message, but the functionality works.

Please renominate if the functionality is broken.
blocking-b2g: spark? → ---
Still having this error, not just in Firefox OS but also in Firefox for android, when trying to use the search functionality (just happened to me :( )
(In reply to Francisco Jordano [:arcturus] [:francisco] from comment #34)
> Still having this error, not just in Firefox OS but also in Firefox for
> android, when trying to use the search functionality (just happened to me :(
> )

Note: See my STR in comment 30 (ie you can reproduce this in Firefox desktop too with the b2g user agent)
FTR I filed bug 1180623 with some STR too. I think we should stop erroring at badly formatted XHTML files. We lost the strictness battle (and I think it's good).
Note that there are a couple of things broken with Google Mail on Firefox. It's not the only issue. 

* Bug 627155
* https://webcompat.com/issues/1333
* https://webcompat.com/issues/367
Was it fixed? 
I tried and I didn't get an XML error message.
I signed in and I was prompted if "Do you really want to use HTML Gmail?" (clicking to "take me to latest Gmail" always redirects me back to the same question).

I chose normal HTML Gmail version.

Opening an email and replying to it did not cause an issue.

################

On the other hand, I can confirm that tapping on the "search" icon reproduces the issue mentioned on comment 30 (XML parsing error).
I added screenshots on 
https://webcompat.com/issues/297#issuecomment-140303194

And I contacted Google about it today.
See Also: → https://webcompat.com/issues/297
Whiteboard: [country-all] [http] [contactready] [xhtml] → [country-all] [http] [sitewait] [xhtml]
This Gmail search issue has been dragging on for some time now.  This is causing me some serious frustration when I am out and need to get to my Gmail All Mail folder and then use the search to find some email that might have been sent some time ago forcing me to search manually page by page which never goes well.

Please see comment 30 regarding issue; let's either get this on it's own ticket or get it fixed please!
Todd,
Yes it's unfortunate but we can't really force Google to change things. I sent a reminder to Google.
(In reply to Karl Dubost :karlcow from comment #43)
> Todd,
> Yes it's unfortunate but we can't really force Google to change things. I
> sent a reminder to Google.

Maybe you should suggest that they may loose customers and not be able to secretly scan people's emails.
Attached image gmail-issues-gecko.jpg — 
Graph Explaining the issues for Google Mail on Firefox Android and Firefox OS. 
The current status quo with Google is that the UI sent to Firefox OS is old and people are not willing to fix it. Fair enough. What I asked is that people have the choice to receive the current Firefox Android version or better the Chrome version with a fixed CSS.
OK thanks for the graphic.  I didn't realize that there was a workable search in Chrome.  I hate to have to use two different browsers but I can live with it.  Firefox you've been replaced at least for this functionality.
Karl, solutions from our side include either bug 1180623 or the webkit unprefixing service ?
Julien, yup. 
But I'm in discussion with Google now. Let's hope it will lead to a good compromise.
(In reply to Karl Dubost :karlcow from comment #48)
> Julien, yup. 
> But I'm in discussion with Google now. Let's hope it will lead to a good
> compromise.

Any update on this Karl?
Flags: needinfo?(kdubost)
On November 2015. 

Google proposed two choices. 

> I synced with the Gmail PM and he said that the team 
> can switch the version sent so that Firefox OS receives 
> the same version as Firefox Android.
> 
> The Gmail PM also suggested that Firefox OS could spoof 
> the user agent string and do the webkit prefix removal 
> itself in order to receive the optimal experience. 
> 
> Alternatively, Gmail could send the full version by default, 
> but it would still require Firefox OS to remove the webkit 
> prefixes. This version would also require Firefox OS to wait
> on the Gmail team to implement the change.
>
> Which of these options do you think would be best?

Since then a lot of work has been done on Firefox Android. 
I'm planning to re-discuss and test this in London. 
And I'm still hoping, we get a full working solution for Firefox Android. Then it will become easier to ask Google to send that to Firefox OS.
Flags: needinfo?(kdubost)
It would be very simple for them to fix the page to put //<![CDATA[ around all scripts.
(In reply to Yuhong Bao from comment #52)
> It would be very simple for them to fix the page to put //<![CDATA[ around
> all scripts.

Not really. This interface was primarily done for feature phones with a quite bad web support. I suppose the current markup has been heavily tested with many feature phones, and because adding CDATA sections could break them, they'd need to test them all over again.
Whiteboard: [country-all] [http] [sitewait] [xhtml] → [country-all] [http] [sitewait] [xhtml] [platform-rel-Google] [platform-rel-Gmail]
platform-rel: --- → ?
Priority: P1 → P5
> This has been a bug since 2014 we're over halfway through 2016 and it's now had it's priority dropped.

Hey Todd -- unfortunately, this bug is out of our control -- it's up to Google to fix.

(To clarify what P5 means For the webcompat team: we won't be spending time to do outreach here. But please feel free to contact Google and ask them to fix the bug, especially if you are a user of Firefox OS).
platform-rel: ? → ---
Closing as we are not working on Firefox OS anymore.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Product: Tech Evangelism → Web Compatibility
Component: Mobile → Site Reports
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: