Closed Bug 1236329 Opened 4 years ago Closed 4 years ago

Error on HP Deskjet 2540 printer configuration page

Categories

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

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla46
Tracking Status
firefox44 + verified
firefox45 + verified
firefox46 + verified

People

(Reporter: laugeo, Assigned: bzbarsky)

References

Details

(Keywords: dev-doc-complete, regression, site-compat)

Attachments

(3 files)

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)
Same error using non-E1O window
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
I guess this is the same as Bug 492933 Comment 42, should be reported to HP.
Blocks: 492933
Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core
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;
[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...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(oriol-bugzilla)
(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.
Flags: needinfo?(oriol-bugzilla)
OS: Linux → All
Hardware: x86_64 → All
Version: 45 Branch → Trunk
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
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.
But... if the spec is changed and Chrome follows the spec, the management page will be broken again on Chrome, right?
No, please see comment 4.
Attachment #8704206 - Flags: review?(bugs) → review+
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
Attachment #8704206 - Flags: approval-mozilla-beta?
Attachment #8704206 - Flags: approval-mozilla-aurora?
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.
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.
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...
Flags: needinfo?(mhenretty)
Flags: needinfo?(apastor)
Flags: needinfo?(mhenretty)
Attachment #8704625 - Flags: review?(gmarty)
Comment on attachment 8704625 [details] [review]
[gaia] mikehenrty:bug-1236329-no-getelementsbytagname > mozilla-b2g:master

LGTM!
Attachment #8704625 - Flags: review?(gmarty) → review+
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
Flags: needinfo?(apastor)
Will take it to beta as it seems critical enough, waiting for this to land on Nightly, verification and then will uplift.
https://hg.mozilla.org/mozilla-central/rev/69719264f890
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
Printer page is  ok  now on Nightly: cool !
(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 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.
Attachment #8704206 - Flags: approval-mozilla-beta?
Attachment #8704206 - Flags: approval-mozilla-beta+
Attachment #8704206 - Flags: approval-mozilla-aurora?
Attachment #8704206 - Flags: approval-mozilla-aurora+
Requesting QE team to do some focused testing around HP printer configuration page if possible. Thanks!
Flags: qe-verify+
Note that the patch is big because it has lots of test changes.  The actual code change is about 1/4 of the patch.
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.
https://hg.mozilla.org/releases/mozilla-aurora/rev/75f2ab55c835
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → FIXED
Marking status-firefox44 as fixed based on comment 35.
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.
Status: RESOLVED → VERIFIED
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.
Flags: qe-verify+
QA Contact: cornel.ionce
You need to log in before you can comment on or make changes to this bug.