JavascriptException: JavascriptException: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIXPCComponents_Utils.import]" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"

RESOLVED INVALID

Status

Testing
Firefox UI Tests
RESOLVED INVALID
2 years ago
2 years ago

People

(Reporter: FlorinMezei, Unassigned)

Tracking

48 Branch
All
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

2 years ago
Several test failures for Firefox 48.0 ondemand update tests, only on Mac OS X (all versions), on the "release-cdntest" channel - only Firefox versions < 44.0 are failing, but RelEng says there is no watershed setup, and manual updates from 42.0 and 43.0.4, on Mac OS X 10.9.5 worked fine (updated directly to 48.0) on a local machine.

Treeherder: https://treeherder.mozilla.org/#/jobs?repo=mozilla-release&revision=c1de04f39fa9&group_state=expanded&filter-tier=3&filter-searchStr=Fxup-release-cdntest(&selectedJob=223842

Traceback (most recent call last):
  File "/Users/Mozauto/jenkins/workspace/ondemand_update/build/venv/lib/python2.7/site-packages/marionette/marionette_test.py", line 332, in run
    self.setUp()
  File "/Users/Mozauto/jenkins/workspace/ondemand_update/build/tests/firefox-ui/tests/update/direct/test_direct_update.py", line 11, in setUp
    UpdateTestCase.setUp(self, is_fallback=False)
  File "/Users/Mozauto/jenkins/workspace/ondemand_update/build/venv/lib/python2.7/site-packages/firefox_ui_harness/testcases.py", line 93, in setUp
    'build_pre': self.software_update.build_info,
  File "/Users/Mozauto/jenkins/workspace/ondemand_update/build/venv/lib/python2.7/site-packages/firefox_puppeteer/api/software_update.py", line 229, in build_info
    'url_aus': self.get_update_url(True),
  File "/Users/Mozauto/jenkins/workspace/ondemand_update/build/venv/lib/python2.7/site-packages/firefox_puppeteer/api/software_update.py", line 347, in get_update_url
    """, script_args=[url])
  File "/Users/Mozauto/jenkins/workspace/ondemand_update/build/venv/lib/python2.7/site-packages/marionette_driver/marionette.py", line 1680, in execute_script
    rv = self._send_message("executeScript", body, key="value")
  File "/Users/Mozauto/jenkins/workspace/ondemand_update/build/venv/lib/python2.7/site-packages/marionette_driver/decorators.py", line 36, in _
    return func(*args, **kwargs)
  File "/Users/Mozauto/jenkins/workspace/ondemand_update/build/venv/lib/python2.7/site-packages/marionette_driver/marionette.py", line 762, in _send_message
    self._handle_error(err)
  File "/Users/Mozauto/jenkins/workspace/ondemand_update/build/venv/lib/python2.7/site-packages/marionette_driver/marionette.py", line 823, in _handle_error
    raise errors.lookup(error)(message, stacktrace=stacktrace)
JavascriptException: JavascriptException: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIXPCComponents_Utils.import]"  nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: dummy file :: func :: line 1"  data: no]
stacktrace:
	execute_script @software_update.py, line 347
	inline javascript, line 1
	src: "          Components.utils.import("resource://gre/modules/UpdateUtils.jsm")"
Florin,

Rail briefly looked into this and "has no idea how to interpret those errors" -- and it looks like some sort of in-product issue to me at first glance. As if there is files missing (system restore/corrupt disk or install/etc)

Any way we can narrow this down to a resolution (all our sides stuff looks sane to us, at first glance).
Flags: needinfo?(florin.mezei)
(Reporter)

Comment 2

2 years ago
(In reply to Justin Wood (:Callek) from comment #1)
> Florin,
> 
> Rail briefly looked into this and "has no idea how to interpret those
> errors" -- and it looks like some sort of in-product issue to me at first
> glance. As if there is files missing (system restore/corrupt disk or
> install/etc)
> 
> Any way we can narrow this down to a resolution (all our sides stuff looks
> sane to us, at first glance).

I have no clues here either. Setting ni? for David, hope he can help.
Flags: needinfo?(florin.mezei) → needinfo?(dburns)
Looks like some versions don't have UpdateUtils.json (omni.ja on mac has no UpdateUtils.jsm, linux64 has 2)

Do you know what would be the impact for users? Thanks
Until we know more, this bug is blocking the 48 release.
Flags: needinfo?(robert.strong.bugs)
Flags: needinfo?(dtownsend)
I confirm, we do have UpdateUtils.jsm in mac dmg files.
just checked 43.0.4.dmg, it that one doesn't have UpdateUtils.jsm, probably we added that file recently and the tests use the new API
Henrik, can you have a look at this when you are back?
Flags: needinfo?(dburns) → needinfo?(hskupin)
this is https://hg.mozilla.org/mozilla-central/rev/9e57875f3f6c (milestone 44.0a1):


-XPCOMUtils.defineLazyModuleGetter(this, "UpdateChannel",
-                                  "resource://gre/modules/UpdateChannel.jsm");
+XPCOMUtils.defineLazyModuleGetter(this, "UpdateUtils",
+                                  "resource://gre/modules/UpdateUtils.jsm");
(In reply to Sylvestre Ledru [:sylvestre] from comment #3)
> Looks like some versions don't have UpdateUtils.json (omni.ja on mac has no
> UpdateUtils.jsm, linux64 has 2)
> 
> Do you know what would be the impact for users? Thanks
> Until we know more, this bug is blocking the 48 release.

As shown above, UpdateUtils.jsm was a module added in Firefox 44, it is expected that it not exist before then. I can't answer the question about impact for users as I don't know what test we are seeing failing here.
Flags: needinfo?(robert.strong.bugs)
Flags: needinfo?(dtownsend)
FTR, this only showed up on mac because other platforms have watersheds at higher than 44, so we don't test older versions for them.

Comment 11

2 years ago
26 automation job failures were associated with this bug yesterday.

Repository breakdown:
* mozilla-release: 26

Platform breakdown:
* osx-10-6: 11
* osx-10-9: 7
* osx-10-11: 4
* osx-10-10: 4

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1291261&startday=2016-08-02&endday=2016-08-02&tree=all
(Reporter)

Comment 12

2 years ago
Another note that it seems I've missed here, but may be of relevance: this only appeared when running ondemand update tests for 48.0 - the problem did not show for 47.0.1 [1] or 47.0[2].

[1] - 47.0.1 - https://treeherder.mozilla.org/#/jobs?repo=mozilla-release&revision=7f5abf95991b&group_state=expanded&filter-tier=3&filter-searchStr=Fxup-release(
[2] - 47.0 - https://treeherder.mozilla.org/#/jobs?repo=mozilla-release&revision=b0310cb90fd0&group_state=expanded&filter-tier=3&filter-searchStr=Fxup-release(
As we agreed a while ago our update tests support Firefox versions up to 3 releases back, or at maximum the last ESR release. In case of the 48.0 release this means Firefox 45.0ESR. Using any version of Firefox before this release is expected to fail.

I do not see any actionable item for me on this bug unless release drivers decided something else for how long we should support update tests.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(hskupin) → needinfo?(sledru)
Resolution: --- → INVALID
Ok, can we introduce some failsafe to avoid getting errors when we test with more? Thanks 

The error message was not clear.
Flags: needinfo?(sledru) → needinfo?(hskupin)
Not sure that I understand your question. But if something goes wrong we clearly want to see an error so I will not try to ignore specific ones. If I would do it this could break us later the other way around, eg. when the file gets renamed or such.

Also the error message directly comes from Marionette. We do not customize any of those. So no, it cannot be easily changed. When reading it, IMO it's perfectly clear. We have a 'NS_ERROR_FILE_NOT_FOUND' for "resource://gre/modules/UpdateUtils.jsm".
Flags: needinfo?(hskupin)
(In reply to Henrik Skupin (:whimboo) from comment #15)
> Not sure that I understand your question.
OK, let me rephrase :)
I would like to avoid the same situation we had last friday. For example, if we test too old versions, I would like our tool to tell us "you are doing something stupid, stupid" ;)
It would not be part of the update tests. An option could be mozmill-ci until we run everything via release promotion somehow. I'm not sure when I would have time for that addition. Florin, I would propose that for now we add this requirement to the QA documentation for releases. Is that ok for you?
Flags: needinfo?(florin.mezei)
(Reporter)

Comment 18

2 years ago
(In reply to Henrik Skupin (:whimboo) from comment #17)
> It would not be part of the update tests. An option could be mozmill-ci
> until we run everything via release promotion somehow. I'm not sure when I
> would have time for that addition. Florin, I would propose that for now we
> add this requirement to the QA documentation for releases. Is that ok for
> you?

Yes, added in red on the config wiki page (before the watershed rules), and will carry that forward (will make sure to apply it for the future configs) - https://wiki.mozilla.org/QA/Desktop_Firefox/Releases/Configs/Fx49b1. Thanks for clarifying this.
Flags: needinfo?(florin.mezei)

Comment 19

2 years ago
26 automation job failures were associated with this bug in the last 7 days.

Repository breakdown:
* mozilla-release: 26

Platform breakdown:
* osx-10-6: 11
* osx-10-9: 7
* osx-10-11: 4
* osx-10-10: 4

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1291261&startday=2016-08-01&endday=2016-08-07&tree=all
You need to log in before you can comment on or make changes to this bug.