Closed
Bug 1326217
Opened 8 years ago
Closed 7 years ago
Intermittent browser_ext_webRequest.js | resource type is correct - Expected: main_frame, Actual: other -
Categories
(WebExtensions :: Request Handling, defect, P2)
WebExtensions
Request Handling
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 1317619
People
(Reporter: intermittent-bug-filer, Assigned: mixedpuppy)
References
Details
(Keywords: intermittent-failure, Whiteboard: [stockwell unknown])
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 4•8 years ago
|
||
it looks like bug 1353689 introduced this failure:
https://treeherder.mozilla.org/#/jobs?repo=autoland&filter-searchStr=asan%20e10s%20bc13&tochange=9b5e7f9f2816a10c4c1bc9caa5e51d03659e3222&fromchange=a418fa4ad28555c8ea6bea2e6a9f2d079822112f&selectedJob=93788054
there are 39 instances in the last week, primarily on linux64-asan.
:bechen, can you look at fixing this soon?
Blocks: 1353689
Flags: needinfo?(bechen)
Updated•8 years ago
|
Whiteboard: [stockwell needswork]
Comment hidden (Intermittent Failures Robot) |
Comment 6•8 years ago
|
||
(In reply to Joel Maher ( :jmaher) from comment #4)
> it looks like bug 1353689 introduced this failure:
> https://treeherder.mozilla.org/#/jobs?repo=autoland&filter-
> searchStr=asan%20e10s%20bc13&tochange=9b5e7f9f2816a10c4c1bc9caa5e51d03659e322
> 2&fromchange=a418fa4ad28555c8ea6bea2e6a9f2d079822112f&selectedJob=93788054
>
> there are 39 instances in the last week, primarily on linux64-asan.
>
> :bechen, can you look at fixing this soon?
Sorry, I don't have any idea about the failure.
Because bug 1353689 enable wpt tests for webvtt, and it seems not relative to this bug?
Can we find someone who knows the test of extentions?
Flags: needinfo?(bechen) → needinfo?(jmaher)
Comment 7•8 years ago
|
||
I did more retriggers and see 1 instance on the push prior, it seems odd that changing web-platform tests would cause this to fail so frequently. This also follows the branches so I am inclined to rule out environment/infra changes- maybe there is an issue with the build.
:andym, can you help find someone to look into this?
Flags: needinfo?(jmaher) → needinfo?(amckay)
Comment 9•8 years ago
|
||
It's worth noting that there have been low-frequency failures for some months.
It looks like the recent increase in frequency is due to failures on linux64-asan/e10s. The regression range noted in comment 4 seems a little late to me: There were linux64-asan failures on April 21 and April 22.
The earliest recent linux64-asan failure that I see is April 19, https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=1eb86cbfac794754da6ed1a8f6adbc4150900415&filter-searchStr=asan+e10s+browser-chrome, but retries on that push have not reproduced the failure -- maybe not significant.
Curiously, some of the earliest linux64-asan failures around April 19 are on try...but I don't see any reliable connection between the bugs associated with those try pushes, their pushes to integration branches and subsequent failures.
This may be too random to track down the cause for the change in frequency. It's probably better to just debug the test.
Flags: needinfo?(gbrown)
Comment hidden (Intermittent Failures Robot) |
Summary: Intermittent browser/components/extensions/test/browser/browser_ext_webRequest.js | resource type is correct - Expected: main_frame, Actual: other - → Intermittent browser_ext_webRequest.js | resource type is correct - Expected: main_frame, Actual: other -
Comment hidden (Intermittent Failures Robot) |
Assignee | ||
Comment 12•8 years ago
|
||
Some observations:
The uptick in occurrence of this failure matches the landing of bug 1326298 in which I converted our stream listener to c++. I'm guessing that contributes to some other timing related issue somewhere else, resulting in more frequent failures. I don't think bug 1326298 is the cause since failures happened prior to it.
On linux, the failure is during nsIRequestObserver.onStopRequest (WebRequest onCompleted)
On Windows, the failure is during nsIRequestObserver.onStartRequest (WebRequest onResponseStarted)
OSX does not seem to fail.
The offending code in WebRequest.jsm is:
let {loadInfo} = channel;
let policyType = (loadInfo ? loadInfo.externalContentPolicyType
: Ci.nsIContentPolicy.TYPE_OTHER);
The test is expecting TYPE_DOCUMENT but is getting TYPE_OTHER. Which could mean loadInfo is not available for some reason. It *WAS* available in other stages of the request, and on Windows, it is available in stages both before and after onResponseStarted.
What I don't understand is why we would have no loadInfo at this stage, since it was available earlier in the request cycle.
shotgun ni? a few people that may have an idea where I should look further...
Flags: needinfo?(kmaglione+bmo)
Flags: needinfo?(honzab.moz)
Flags: needinfo?(bzbarsky)
Flags: needinfo?(amckay)
Comment 13•8 years ago
|
||
I don't have any bright ideas offhand. It's a bit odd that nsWebRequestListener doesn't have threadsafe refcounting, and think we should fix that, but I'd expect that to hit asserts in debug builds if it were being a problem in practice right now.
In terms of things I would strongly consider logging (maybe only if some test-only pref is set, so we can examine logs if it fails but don't create noise in general):
1) Is loadInfo falsy, or is loadInfo.externalContentPolicyType wrong?
2) Is the "channel" object the one we're expecting?
Flags: needinfo?(bzbarsky)
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 16•7 years ago
|
||
this has picked up a lot last week, and settled back down this week, I really don't like that this has been at 20+ failures/week for a couple months.
Assignee | ||
Comment 17•7 years ago
|
||
I'll try to get to this in the near future.
Assignee: nobody → mixedpuppy
Priority: -- → P2
Comment hidden (Intermittent Failures Robot) |
Comment 19•7 years ago
|
||
I'm not sure what I could add here except a suggestion to add some logs to the tests (could influence timing) or to obtain a log (nsHttp:5 at least?) from a faulty run.
Flags: needinfo?(honzab.moz)
Assignee | ||
Comment 20•7 years ago
|
||
Comment 21•7 years ago
|
||
:mixedpuppy- any good information from your try push?
Assignee | ||
Comment 22•7 years ago
|
||
Only that channel.loadInfo is occasionally not set, don't know why yet. This will have to wait to at least work week.
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 27•7 years ago
|
||
this has become very infrequent
Whiteboard: [stockwell needswork] → [stockwell unknown]
Comment hidden (Intermittent Failures Robot) |
Assignee | ||
Updated•7 years ago
|
Component: WebExtensions: Untriaged → WebExtensions: Request Handling
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 31•7 years ago
|
||
This hasn't happened in ages, I think tests got shuffled around and the duplicate took the place of this one
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Updated•7 years ago
|
Flags: needinfo?(kmaglione+bmo)
Updated•6 years ago
|
Product: Toolkit → WebExtensions
You need to log in
before you can comment on or make changes to this bug.
Description
•