User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

I opened my MBB device page by entering "192.168.8.1" in address bar of a new tab.
My device is Huawei Mobile Broadband LTE Wingle E8372.

Actual results:

The device page opens up but some commands given on page do not work any more.
For example, if I click on Delete button to delete an SMS on MBB SIM, it doesn't get deleted. Similarly, if I logout, it doesn't gets logged out, unless I repeat the procedure three to four times by clicking logout and refreshing the webpage each time. Some commands (not all) have simply stopped working correctly any more.

Expected results:

The commands should have worked as they used to do in this browser previously and
as they still do in other browsers like opera and chrome.

Hi Adnaan, Thanks for Taking the time to report this issue, Unfortunately we do not have that device and we cannot reproduce this issue but maybe you can help us get to the bottom of this issue.

First things first, can you retest this issue in Safe mode using the following steps: https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode it might be related to addons or other extensions.

Then If the issue still occurs in safe mode can you also try our latest Nightly Build? you can find it here: https://nightly.mozilla.org/ and see if the issue still occurs there as well.

I tried Safe Mode and then Nightly. Issue still occurs even in the Safe mode and Nightly as well.

This seems to me like a Networking issue but I am not sure, Please change the component for it if there is a better one, I think there is a miscommunication between the mobile internet dongle and Firefox.

Probably, you are right. It used to work perfectly in Firefox previously but probably from December 2018 or January 2019, I am facing this issue, I checked the system proxy settings and networking part also but no use. Other browsers work well with the device, so I can't think of any device malfunction.

Per Comment 4, looks like a regression.
Could you please help us to find the regression range, Adnann?
https://mozilla.github.io/mozregression/quickstart.html

Thanks!

Ok. I tried regression and it turned out that last good version was 26-09-2018 and the first bad one was 27-09-2018.

Found commit message:
Bug 1398718 - change default pref to on for lowercase header names in XHR.getAllResponseHeaders; r=hsivonen

change default pref to on for lowercase header names in XHR.getAllResponseHeaders

Differential Revision: https://phabricator.services.mozilla.com/D6589

Hello Adnaan,
Could you please confirm if the issue is gone after toggle the "dom.xhr.lowercase_header.enabled" in about:config to false?
Thanks!

Needinfo for comment 9

Yes, the issue is gone after toggle the "dom.xhr.lowercase_header.enabled" in about:config to false!!!

Hello Thomas,
Could you take a look since it's regressed by Bug 1398718? Thanks.

Unfortunately I don't know what I can do without having that device model to test with. We're already going to reach out to Huawei about another device having this problem in bug 1519456, so let's mark this as a related issue.

But to summarize my findings in that bug, either the device is doing something browser-specific, or Chromium might be treating it differently from it's usual behavior, as my own router is getting lowercased headers from Chromium.

Adnaan Baig, would you be willing to inspect the network headers that Chrome is sending your device, by checking the headers in the Chrome developer tools network panel after it sends some? Because if it is sending lowercased values, then it's likely the Wingle doing something special, and we'll just have to wait for Huawei's insight.

Well, it looks like it is sending lower case values. I am attaching an image of the Delete-SMS command headers.

Hmm, interesting. Thanks for checking!

The response header names there are mixed-case, so there's a chance Chromium might be doing something special. Would you be willing to try one more test?

If you visit any page on your Wingle using Chrome/Opera, then open the developer tools' console tab, and then copy-paste this line of code into it and press enter:

x=new XMLHttpRequest(); x.open("get",""); x.onloadend=function() { console.log(x.getAllResponseHeaders()) }; x.send();

Does it output all-lowercased header names like this:

content-encoding: gzip
content-type: text/html

Or does it show mixed-case results like this?

Content-Encoding: gzip
Content-type: text/html

If Chromium shows mixed-case names then it may indeed be doing something special.

The output of command in console tab was all lower case. I am attaching its image.

I am also attaching image of headers tab Opera, it was just like Chrome, i.e. mixed casing.

I have a Huewei E5377Ts-32 with the same problem.

I can't remove SMSs from Firefox or from the last Safari available for El Capitan. I can remove SMSs from Chromium.

Marking P1 to figure out what to do. The Safari problem suggests that our present behavior isn't totally unreasonable.

Needinfoing myself to remind me to investigate if there's sniffing for Chromium.

I have found that the device is working fine with Internet Explorer 11 also.

Reason why this breaks in Firefox: The JS code calls getAllResponseHeaders() and then looks for particular reader names both as mixed-case and as all-lower-case using indexOf. However, the headers of interest start with an underscore, so they sort before any names starting with a lower case letter. Before lower-casing, some headers that started with an upper-case letter sorted before the underscore. The code has a bug that compares the return value of indexOf to > 0 as opposedo to > -1, so when the match is at the start of the string, the code thinks there's no match.

Up next: Figuring out why it doesn't fail in Chrome.

Chrome doesn't perform the sorting specced in https://fetch.spec.whatwg.org/#concept-header-list-sort-and-combine .

annevk, why do we need to sort the headers?

We could fix this either by not sorting or by using a custom sort order that'd do the sorting as if the headers were all uppercased instead of lowercased.

Since intermediaries can adjust the order (and combining header values also affects order a bit depending on how you look at it) this seemed the most robust, especially given that HTTP doesn't signal any importance to the received order (other than pre-combining order for a single header name).

This is tested by the first test of xhr/getallresponseheaders.htm which only Chrome fails. I left a comment in https://bugs.chromium.org/p/chromium/issues/detail?id=651750 informing them.

(In reply to Anne (:annevk) from comment #26)

Since intermediaries can adjust the order (and combining header values also affects order a bit depending on how you look at it) this seemed the most robust, especially given that HTTP doesn't signal any importance to the received order (other than pre-combining order for a single header name).

How bad would it be to do the sorting as upper case?

Does not seem particularly bad, other than being a bit of work (more tests, specification change) and there's a potential for Chrome or Safari to be against it (though that seems unlikely).

This makes the underscore sort after letters, which works around
a bug in the admin UI of Huawei portable wifi hotspots.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=59adbbf111da5ceeb702e4cf014fa4f6f5de21da

Filed spec issue: https://github.com/whatwg/xhr/issues/248

AFAICT, there's no test coverage for sorting non-alphabetic characters relative to alphabetic ones.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=67dc65912c3a02281d5c2887d10dbe8cb56f9d40

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:hsivonen, could you have a look please?
For more information, please visit auto_nag documentation.

https://hg.mozilla.org/mozilla-central/rev/40d1bf211aa0