Closed Bug 1326217 Opened 7 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)

Product:
WebExtensions
Component:
Request Handling
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1317619

People

(Reporter: intermittent-bug-filer, Assigned: mixedpuppy)

References

Details

(Keywords: intermittent-failure, Whiteboard: [stockwell unknown]) 

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)
Whiteboard: [stockwell needswork]
(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)
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)
:gbrown, do you have further thoughts here?
Flags: needinfo?(gbrown)
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)
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 -
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)
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)
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.
I'll try to get to this in the near future.
Assignee: nobody → mixedpuppy
Priority: -- → P2
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)
:mixedpuppy- any good information from your try push?
Only that channel.loadInfo is occasionally not set, don't know why yet.  This will have to wait to at least work week.
this has become very infrequent
Whiteboard: [stockwell needswork] → [stockwell unknown]
Component: WebExtensions: Untriaged → WebExtensions: Request Handling
See Also: → 1317619
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
Flags: needinfo?(kmaglione+bmo)
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.