1236329 - Error on HP Deskjet 2540 printer configuration page

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[laugeo]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160102004007

Steps to reproduce:

Using newer Firefox (Nightly or Developer edition), try to  access HP Deskjet 2540 printer/scanner  page  , in my case http://192.168.1.100/ 


Actual results:

Error is displayed in the browser: "you can't use this function because it was desactivated"


Expected results:

Firefox show normal printer page , as it was the case with older Firefox version (works with FF 38 , may be later version)

Comment 1

[laugeo]

Same error using non-E1O window

Comment 2

[Kohei Yoshino [:kohei]]

I guess this is the same as Bug 492933 Comment 42, should be reported to HP.

Comment 3

[Kohei Yoshino [:kohei]]

Added a developer note to https://www.fxsitecompat.com/en-US/docs/2015/getelementsbytagname-now-matches-localname-instead-of-tagname/

Comment 4

[Oriol Brufau [:Oriol]]

Yes, I have the same problem with HP Officejet Pro 8610 printer.

HP programmers are mad. First, they use browser sniffing, and then they use feature detection.
> if (e.browser.msie || e.browser.mozilla && f >= 1.9) {
>   e.hlp.supXmlNs = true
> } else {
>   var g = e.parseXML('<ns:root xmlns:ns=\'!empty\'><ns:elm></ns:elm></ns:root>');
>   e.hlp.supXmlNs = e('ns\\:elm', g).length > 0
> }
They should remove the browser sniffing part and only use the feature detection.

As a workaround, I use this userscript:
> // @run-at document-idle
> $.hlp.supXmlNs = false;

Comment 5

[Boris Zbarsky [:bzbarsky]]

[Tracking Requested - why for this release]: Breaks HP management web pages

We need to decide whether to back out bug 492933 and if so what the standard needs to say...  I'm not super-convinced about shipping something that will break all this HP stuff, and I bet neither is Microsoft.  Given that, seems to me like we should change the spec to the current Gecko/Microsoft behavior, if Blink/Webkit are willing to implement it.

Failing that, if someone has access to this page and is willing to poke around inside it, I'd love to know how e.browser.mozilla gets set and how "f" gets set in the code snippet in comment 4.  Maybe we can lie to this page about who we are or something...

Comment 6

[Oriol Brufau [:Oriol]]

(In reply to Boris Zbarsky [:bz] (Vacation until Jan 4) from comment #5)
> I'd love to know how e.browser.mozilla gets set and how
> "f" gets set in the code snippet in comment 4. Maybe we can lie to this
> page about who we are or something...

`e` is the parameter of an IIFE which is called with `jQuery` as the argument. And `f` is `parseFloat(e.browser.version)`.

The code looks like
> (function(e) {
>   // ...
>   function a() {
>     if (e.hlp.supXmlNs === undefined) {
>       var f = parseFloat(e.browser.version);
>       if (e.browser.msie || e.browser.mozilla && f >= 1.9) {
>         e.hlp.supXmlNs = true
>       } else {
>         var g = e.parseXML('<ns:root xmlns:ns=\'!empty\'><ns:elm></ns:elm></ns:root>');
>         e.hlp.supXmlNs = e('ns\\:elm', g).length > 0
>       }
>     }
>     return e.hlp.supXmlNs
>   }
>   a()
> })(jQuery);

Then they use `$.hlp.supXmlNs` like this
> function _NS(a) {
>   if ($.hlp.supXmlNs) {
>     return a
>   } else {
>     return a.replace(/\w*\\:/g, '')
>   }
> }
> $(_NS('ledm\\:ManifestURI'), $.hlp.ledm.DiscoveryTree).each(function() {
>   // ...
> });

I think jQuery gets the browser values like this
> var userAgent = navigator.userAgent.toLowerCase();
> jQuery.browser = {
>   version: (userAgent.match(/.+(?:rv|it|ra|ie)[\/: ]([\d.]+)/) || [])[1],
>   mozilla: /mozilla/.test(userAgent) && !/(compatible|webkit)/.test(userAgent)
> };

So changing `navigator.userAgent` might work but probably it would break lots of other sites.

By the way, this bug affects all platforms, not only Linux 64.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Attachment: Back out the patch for bug 492933 (revision d8012b35413b) because it's not web-compatible in practice

This just backs out bug 492933.  I filed https://github.com/whatwg/dom/issues/143 on the spec.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Oriol, thanks for digging into the code there.  It does look like avoiding this sniffing would not be particularly simple; we'd have to add either "compatible" or "webkit" to our UA string, and at least the latter is bound to be problematic...  Seems like making the spec align with IE and Gecko here is a better idea.

Comment 9

[Kohei Yoshino [:kohei]]

But... if the spec is changed and Chrome follows the spec, the management page will be broken again on Chrome, right?

Comment 10

[Boris Zbarsky [:bzbarsky]]

No, please see comment 4.

Comment 11

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3aca7055f52f

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8704206 [details] [diff] [review]
Back out the patch for bug 492933 (revision d8012b35413b) because it's not web-compatible in practice

Approval Request Comment
[Feature/regressing bug #]: Bug 492933
[User impact if declined]: HP printer configuration pages will stop working in Firefox.
[Describe test coverage new/current, TreeHerder]: We have tests.
[Risks and why]: Should be pretty low risk.  Just backing out bug 492933.
[String/UUID change made/needed]: None

Comment 13

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Something from this push turned browser_video_test.js permafail on mulet:

https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&fromchange=4ce756db0a3b&group_state=expanded&filter-tier=1&filter-searchStr=605e28e4b0be961dd6500eccef1565f8991d56fb&selectedJob=19321095
Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/594ed9a5ad27

Comment 14

[Boris Zbarsky [:bzbarsky]]

Looks like it was this patch.  See https://treeherder.mozilla.org/#/jobs?repo=try&revision=ff5309ac3c31

Looking into it, insofar as it's possible to look into anything with mulet.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Oh, and it looks like the failing gaia test (apps/system/test/marionette/browser_video_test.js) got added on Dec 15, which is why this was not an issue before the changes for bug 492933.

Comment 16

[Boris Zbarsky [:bzbarsky]]

And the test has this bit in apps/system/test/marionette/lib/video_player.js:

      var systemFrame = document.getElementsByTagName('iframe')[0];

There's a good chance that's actually a <xul:iframe>, with the prefix, or some such.  It also has:

      var video = frame.contentWindow.document.getElementsByTagName('video')[0];

which is not likely to be the problem.

I haven't found yet where the actual documents involved are defined as markup, or why these calls aren't just using querySelector like the other similar stuff around....  The good news, I guess, is that this landed after the last branchpoint so at least we don't need to deal with getting the gaia that aurora/beta pull fixed...

Comment 17

[GitHub Autolander Bot]

Attachment: [gaia] mikehenrty:bug-1236329-no-getelementsbytagname > mozilla-b2g:master

Comment 18

[Guillaume Marty [:gmarty]]

Comment on attachment 8704625 [details] [review]
[gaia] mikehenrty:bug-1236329-no-getelementsbytagname > mozilla-b2g:master

LGTM!

Comment 19

[Michael Henretty [:mikehenrty][:mhenretty]]

Ok, this test no longer uses getElementsByTagName in the chrome process. Let's see if this patch can be backed out again.

Gaia master: https://github.com/mozilla-b2g/gaia/commit/24e396513a6409870db425f48e4998d7160d267f

Comment 20

[Michael Henretty [:mikehenrty][:mhenretty]]

Try push from b2g-inbound: https://treeherder.mozilla.org/#/jobs?repo=try&revision=28194174c4bc

Comment 22

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/69719264f890

Comment 23

[Sylvestre Ledru [:Sylvestre]]

Regression, tracking!

Comment 24

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Will take it to beta as it seems critical enough, waiting for this to land on Nightly, verification and then will uplift.

Comment 25

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/69719264f890

Comment 26

[laugeo]

Printer page is  ok  now on Nightly: cool !

Comment 27

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

(In reply to laugeo from comment #26)
> Printer page is  ok  now on Nightly: cool !

Awesome! Thank you so much for your well-timed verification and comment. :)

Comment 28

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8704206 [details] [diff] [review]
Back out the patch for bug 492933 (revision d8012b35413b) because it's not web-compatible in practice

This patch is big but mostly a backout and was verified to fix the HP print issues by the bug filer, seems safe to uplift to beta44 and aurora45.

Comment 29

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Requesting QE team to do some focused testing around HP printer configuration page if possible. Thanks!

Comment 30

[Boris Zbarsky [:bzbarsky]]

Note that the patch is big because it has lots of test changes.  The actual code change is about 1/4 of the patch.

Comment 31

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/02e0b7cd62ac

Comment 32

[Ryan VanderMeulen [:RyanVM]]

Backed out from Aurora for wpt failures.
https://treeherder.mozilla.org/logviewer.html#?job_id=1739739&repo=mozilla-aurora

https://hg.mozilla.org/releases/mozilla-aurora/rev/3019eb49d708

Comment 33

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch to use for Aurora and beta

Sorry, my fault. One of the wpt tests got renamed and I didn't notice that it has only happened on trunk, so the expectations file was wrong for aurora/beta.  This patch should have the right expectations file.

Comment 34

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/75f2ab55c835

Comment 35

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-beta/rev/56000c5e51e7

Comment 36

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Marking status-firefox44 as fixed based on comment 35.

Comment 37

[Cornel Ionce [:noni] [Hubs QA]]

We've tested this fix using Firefox 44 beta 8, build ID: 20160111185352 on Windows 7 64bit, Windows 10 64bit, Mac OS X 10.8.5 and Ubuntu 12.04 32bit and did not encounter any error.

Comment 38

[Cornel Ionce [:noni] [Hubs QA]]

No issues were encountered while tested using Firefox 45 beta 7 (buildID 20160215141016) and latest 46.0a2 (buildID 20160216004009) on Windows 10 x64, Mac OS X 10.9.5 and Ubuntu 12.04 x86.