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

Status: RESOLVED WONTFIX

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

Description

[(no longer active)]

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.

Comment 1

[Karl Dubost💡 :karlcow]

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.

Comment 2

[(no longer active)]

(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.

Comment 3

[Hallvord R. M. Steen [:hallvors]]

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?

Comment 4

[(no longer active)]

Not that I know of.

Comment 5

[Karl Dubost💡 :karlcow]

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

Comment 6

[gabriele.vidali]

I confirm this bug both when replying and forwarding emails

Comment 7

[Hallvord R. M. Steen [:hallvors]]

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?

Comment 8

[gabriele.vidali]

If I try opening  https://mail.google.com/mail/mu/ I got a forbidden message, error 403

Comment 9

[gabriele.vidali]

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

Comment 10

[Hallvord R. M. Steen [:hallvors]]

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?

Comment 11

[gabriele.vidali]

(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

Comment 12

[(no longer active)]

(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.

Comment 13

[Hallvord R. M. Steen [:hallvors]]

(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.

Comment 15

[(no longer active)]

Bug 1020058 might contain another STR, can you please check?  Thanks!

Comment 19

[Aaron Train [:aaronmt]]

I think Android is affected here too as per bug 1064208. I see an XML error too on Nightly (09/08).

Comment 21

[Rémy Hubscher (:natim)]

Maybe in case of xhtml+xml content type we could fallback to the xHTML parser if the XML one fails.

Comment 22

[Mike Taylor [:miketaylr]]

(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/.

Comment 23

[Karl Dubost💡 :karlcow]

Related to Mike's comment: Bug 941241

Comment 24

[Yuhong Bao]

Personally, I hope iOS can remove the automatic fallback to text/html too.

Comment 25

[Hallvord R. M. Steen [:hallvors]]

(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..)

Comment 26

[Yuhong Bao]

(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.

Comment 27

[Yuhong Bao]

(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.

Comment 28

[Karl Dubost💡 :karlcow]

(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.

Comment 29

[Yuhong Bao]

(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.

Comment 30

[Paul Theriault [:pauljt] (no longer reading bugmail)]

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")

Comment 31

[Yuhong Bao]

> 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.

Comment 32

[Paul Theriault [:pauljt] (no longer reading bugmail)]

[Blocking Requested - why for this release]:
Broken Gmail is a blocker to using this as a dogfood device.

Comment 33

[Francisco Jordano [:arcturus] [:francisco]]

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.

Comment 34

[Francisco Jordano [:arcturus] [:francisco]]

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 :( )

Comment 35

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(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)

Comment 36

[Julien Wajsberg [:julienw]]

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).

Comment 37

[Karl Dubost💡 :karlcow]

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

Comment 39

[Karl Dubost💡 :karlcow]

Was it fixed? 
I tried and I didn't get an XML error message.

Comment 40

[Armen [:armenzg]]

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).

Comment 41

[Karl Dubost💡 :karlcow]

I added screenshots on 
https://webcompat.com/issues/297#issuecomment-140303194

And I contacted Google about it today.

Comment 42

[Todd]

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!

Comment 43

[Karl Dubost💡 :karlcow]

Todd,
Yes it's unfortunate but we can't really force Google to change things. I sent a reminder to Google.

Comment 44

[Todd]

(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.

Comment 45

[Karl Dubost💡 :karlcow]

Attachment: 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.

Comment 46

[Todd]

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.

Comment 47

[Julien Wajsberg [:julienw]]

Karl, solutions from our side include either bug 1180623 or the webkit unprefixing service ?

Comment 48

[Karl Dubost💡 :karlcow]

Julien, yup. 
But I'm in discussion with Google now. Let's hope it will lead to a good compromise.

Comment 50

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(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?

Comment 51

[Karl Dubost💡 :karlcow]

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.

Comment 52

[Yuhong Bao]

It would be very simple for them to fix the page to put //<![CDATA[ around all scripts.

Comment 53

[Julien Wajsberg [:julienw]]

(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.

Comment 54

[Todd]

I think the writing is on the wall.  The end of Mozilla is near.  This has been a bug since 2014 we're over halfway through 2016 and it's now had it's priority dropped.  I guess that means that free coding is going the way of the Dodo.

Comment 55

[Mike Taylor [:miketaylr]]

> 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).

Comment 56

[Karl Dubost💡 :karlcow]

Closing as we are not working on Firefox OS anymore.