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

RESOLVED WONTFIX

Status

defect
P5
major
RESOLVED WONTFIX
5 years ago
3 months ago

People

(Reporter: Ehsan, Assigned: karlcow)

Tracking

(Depends on 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 attachment)

Reporter

Description

5 years ago
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.
Assignee

Comment 1

5 years ago
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
Component: English US → Mobile
Flags: needinfo?(ehsan)
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
Whiteboard: [country-all] [http] [notcontactready]
Reporter

Comment 2

5 years ago
(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)
Reporter

Comment 4

5 years ago
Not that I know of.
Flags: needinfo?(ehsan)
Assignee

Comment 5

5 years ago
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

5 years ago
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?

Comment 8

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

Comment 9

5 years ago
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?

Comment 11

5 years ago
(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
Reporter

Comment 12

5 years ago
(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]
Reporter

Updated

5 years ago
Duplicate of this bug: 1020058
Reporter

Comment 15

5 years ago
Bug 1020058 might contain another STR, can you please check?  Thanks!
Reporter

Updated

5 years ago
Depends on: 1044332
Assignee

Updated

5 years ago
Assignee: nobody → kdubost
Status: NEW → ASSIGNED

Updated

5 years ago
Duplicate of this bug: 1049356

Updated

5 years ago
Duplicate of this bug: 1018571

Updated

5 years ago
Duplicate of this bug: 796612
I think Android is affected here too as per bug 1064208. I see an XML error too on Nightly (09/08).
Duplicate of this bug: 1064208
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/.
Assignee

Comment 23

5 years ago
Related to Mike's comment: Bug 941241
See Also: → 941241

Comment 24

5 years ago
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..)

Comment 26

5 years ago
(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

5 years ago
(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.
Assignee

Comment 28

5 years ago
(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

5 years ago
(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")

Comment 31

4 years ago
> 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).
Assignee

Comment 37

4 years ago
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
Duplicate of this bug: 1180650
Assignee

Comment 39

4 years ago
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).
Assignee

Comment 41

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

And I contacted Google about it today.
Whiteboard: [country-all] [http] [contactready] [xhtml] → [country-all] [http] [sitewait] [xhtml]

Comment 42

4 years ago
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!
Assignee

Comment 43

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

Comment 44

4 years ago
(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.
Assignee

Comment 45

4 years ago
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

4 years ago
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 ?
Assignee

Comment 48

4 years ago
Julien, yup. 
But I'm in discussion with Google now. Let's hope it will lead to a good compromise.
Duplicate of this bug: 1239325
(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)
Assignee

Comment 51

3 years ago
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)

Comment 52

3 years ago
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: --- → ?
Assignee

Updated

3 years ago
Priority: P1 → P5
Comment hidden (offtopic)
> 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: ? → ---
Assignee

Comment 56

9 months ago
Closing as we are not working on Firefox OS anymore.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 months ago
Resolution: --- → WONTFIX
Component: Mobile → Mobile
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.