Intermittent e10s browser_bug734076.js | uncaught exception - uncaught exception: Load of from http://mochi.test:8888/ denied. at undefined, Test timed out, Found a tab

RESOLVED FIXED

Status

()

P5
normal
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: philor, Assigned: Gijs)

Tracking

(Blocks: 1 bug, {intermittent-failure})

unspecified
intermittent-failure
Points:
---

Firefox Tracking Flags

(e10s+, firefox49 wontfix, firefox50 fixed, firefox51 fixed, firefox52 fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Updated

3 years ago
tracking-e10s: --- → ?
Comment hidden (Intermittent Failures Robot)
Blocks: 984139
tracking-e10s: ? → +
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Intermittent e10s test failure
Priority: -- → P5
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
status-firefox49: --- → affected
status-firefox50: --- → affected
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Created attachment 8780161 [details] [diff] [review]
request longer timeout in browser_bug734076.js mochitest

This is triggering a lot, not easy to split, and should just have a longer timeout already.

I keep getting bit by this one.
Attachment #8780161 - Flags: review?(mconley)
(In reply to Lee Salzman [:lsalzman] from comment #30)
> Created attachment 8780161 [details] [diff] [review]
> request longer timeout in browser_bug734076.js mochitest
> 
> This is triggering a lot, not easy to split, and should just have a longer
> timeout already.
> 
> I keep getting bit by this one.

The failure seems to be due to a load failure being thrown here: http://searchfox.org/mozilla-central/rev/d83f1528dbcb1e837d99cf5b6c36a90b03bf0e77/toolkit/modules/BrowserUtils.jsm#81

I don't fully understand how a longer timeout can prevent that. What am I missing?
Flags: needinfo?(lsalzman)
Comment on attachment 8780161 [details] [diff] [review]
request longer timeout in browser_bug734076.js mochitest

Okay, reexamining the timings on this one, yes, it looks like the access denied is happening well before the timeout. Not the other way around. Then a longer timeout won't fix this one.
Attachment #8780161 - Attachment is obsolete: true
Flags: needinfo?(lsalzman)
Attachment #8780161 - Flags: review?(mconley)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
This is exceedingly frequent. Any chance you can help find an owner?
Flags: needinfo?(dolske)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
(Reporter)

Updated

3 years ago
Keywords: leave-open
Whiteboard: [test disabled on Linux e10s]

Comment 56

3 years ago
Pushed by philringnalda@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/213d45a523d1
Skip browser_bug734076.js on Linux e10s for constant failures
Comment hidden (Intermittent Failures Robot)
If you have cycles, this one is justifiably frequent enough to warrant asking you to look too :P. Well, it was before comment 57 anyway.
status-firefox49: affected → wontfix
status-firefox51: --- → affected
Flags: needinfo?(gijskruitbosch+bugs)
(Assignee)

Comment 60

3 years ago
Reading the code here, I *think* the image's mediaURL is "empty string", which is why there's no target URI that shows up in the error message that denies the load.

mediaURL is based on the image's currentURI property, and it'll be empty string if currentURI is null, which is the case for an <img> that has nothing loaded and no src attribute.

There's two things going on, then:

1) I *think* the test is racy in that it's possible for the image to not have a source when we invoke the context menu. Maybe we should be waiting for a load/error event on it, or something?

2) I actually think we shouldn't show the 'view image' menu when there's no mediaURL. It won't do the right thing.

Neil, seems you adapted this test for e10s, does the above seem sane to you?
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(enndeakin)

Comment 61

2 years ago
Seems ok, but I just adapted the test.
Flags: needinfo?(enndeakin)
(Assignee)

Comment 62

2 years ago
https://treeherder.mozilla.org/#/jobs?repo=try&revision=27ab12c4ee0b

Jared, I know you've looked at our context menu tests in the past, also for e10s. Does comment #60 sound sane to you?
Flags: needinfo?(dolske) → needinfo?(jaws)
(Assignee)

Comment 63

2 years ago
(In reply to :Gijs Kruitbosch from comment #62)
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=27ab12c4ee0b


From the trypush, it seems the context menu state is missing the actual "view image" entry because onImage is false. That means (2) from comment 60 is basically wrong (ie we already don't show this item in this case).

What's more confusing is *why* mediaURL is empty and why onImage is false. The screenshot ( https://public-artifacts.taskcluster.net/VupneFGlSF-N4itmlOZLSA/0/public/test_info//mozilla-test-fail-screenshot_62oIgr.png ) would suggest there *is* an image under the cursor when the context menu shows up.

Re-pushed with more logging:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=c516c02f09851f3021ffbe5df45a0c953bb74d4d
(Assignee)

Comment 64

2 years ago
OK, so judging from the log at https://treeherder.mozilla.org/#/jobs?repo=try&revision=c516c02f09851f3021ffbe5df45a0c953bb74d4d&selectedJob=28534591 the problem is that the context menu target element isn't actually the <img> element.

Jared, can you take a look at this test and/or give me some high-level pointers as to how the gContextMenu.target stuff is supposed to even work in the e10s case? Like, that node is a content element, right? Do we just use a CPOW (I thought those were outlawed in browser code now?) or do we somehow recreate it on the parent side or how does this work?

Comment 65

2 years ago
I think the target is either still a cpow or is null.

If you need to send some info from the content process, there is a gContextMenuContentData which gets populated in the remote case. The child process handling is at https://dxr.mozilla.org/mozilla-central/source/browser/base/content/content.js#86
(Assignee)

Comment 66

2 years ago
(In reply to Neil Deakin from comment #65)
> I think the target is either still a cpow or is null.

Looks like it's a CPOW.

> If you need to send some info from the content process, there is a
> gContextMenuContentData which gets populated in the remote case. The child
> process handling is at
> https://dxr.mozilla.org/mozilla-central/source/browser/base/content/content.
> js#86

Hm, well, we could send the data from the content process here (e.g. mediaURL and onImage/onLoadedImage and so on) but the main question I have right now is why the target isn't the <img>, but something else... I'll poke at this some more, probably with more trypushes.
Flags: needinfo?(jaws) → needinfo?(gijskruitbosch+bugs)
(Assignee)

Comment 68

2 years ago
(In reply to :Gijs Kruitbosch from comment #67)
> remote:  
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=ae1fb406b5a33c722ef424ccab22140b27e72086

So instead of the <img> we're getting the <body> as the event target for the contextmenu event. I... I don't even know how/why that is possible. :-\
Comment hidden (mozreview-request)
(Assignee)

Updated

2 years ago
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Flags: needinfo?(gijskruitbosch+bugs)

Comment 71

2 years ago
mozreview-review
Comment on attachment 8798471 [details]
Bug 1277750, fix intermittent bug734076.js test failure on linux64 e10s by forcing a size onto the <img> element loading an invalid URI,

https://reviewboard.mozilla.org/r/83944/#review82780

I think your story in the commit message might be right!

::: browser/base/content/test/general/browser_bug734076.js:100
(Diff revision 1)
>      let popupShownPromise = BrowserTestUtils.waitForEvent(contentAreaContextMenu, "popupshown");
>      yield BrowserTestUtils.synthesizeMouse(test.element, 3, 3,
>            { type: "contextmenu", button: 2 }, gBrowser.selectedBrowser);
>      yield popupShownPromise;
> +    info("onImage: " + gContextMenu.onImage);
> +    info("target: " + gContextMenu.target.tagName);

Do you want to keep these in for a while? If you think it's useful for future monitoring...
Attachment #8798471 - Flags: review?(mdeboer) → review+
(Assignee)

Comment 72

2 years ago
mozreview-review
Comment on attachment 8798471 [details]
Bug 1277750, fix intermittent bug734076.js test failure on linux64 e10s by forcing a size onto the <img> element loading an invalid URI,

https://reviewboard.mozilla.org/r/83944/#review82786

::: browser/base/content/test/general/browser_bug734076.js:100
(Diff revision 1)
>      let popupShownPromise = BrowserTestUtils.waitForEvent(contentAreaContextMenu, "popupshown");
>      yield BrowserTestUtils.synthesizeMouse(test.element, 3, 3,
>            { type: "contextmenu", button: 2 }, gBrowser.selectedBrowser);
>      yield popupShownPromise;
> +    info("onImage: " + gContextMenu.onImage);
> +    info("target: " + gContextMenu.target.tagName);

Yeah, I think keeping this is going to be helpful to check what's going on if we continue to see (maybe less frequent?) intermittents, without hurting anything, so we might as well keep it.

TBH, after some years of occasionally fixing intermittents, I've come to believe that more info() debugging in tests by default would be a good pattern for us to adopt. Right now some tests just have a couple of yields and one or two actual test assertions, and if there are timeouts or there's "weird" behaviour, the first 5 trypushes are about figuring out where exactly what exactly is broken. More logging would help a lot for that. For non-failing tests we don't even put this in the log by default (have to use SimpleTest.requestCompleteLog()) so it doesn't otherwise affect anything.

Comment 73

2 years ago
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/c01ac374bce4
fix intermittent bug734076.js test failure on linux64 e10s by forcing a size onto the <img> element loading an invalid URI, r=mikedeboer
(Assignee)

Comment 75

2 years ago
Looks fixed to me when looking at orange factor.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Keywords: leave-open
Resolution: --- → FIXED
(Assignee)

Updated

2 years ago
status-firefox52: --- → fixed
(Assignee)

Comment 76

2 years ago
Comment on attachment 8798471 [details]
Bug 1277750, fix intermittent bug734076.js test failure on linux64 e10s by forcing a size onto the <img> element loading an invalid URI,

Approval Request Comment
[Feature/regressing bug #]: intermittent orange on e10s
[User impact if declined]: ditto
[Describe test coverage new/current, TreeHerder]: the test is passing
[Risks and why]: low risk, test-only change
[String/UUID change made/needed]: no
Attachment #8798471 - Flags: approval-mozilla-beta?
Attachment #8798471 - Flags: approval-mozilla-aurora?
Comment on attachment 8798471 [details]
Bug 1277750, fix intermittent bug734076.js test failure on linux64 e10s by forcing a size onto the <img> element loading an invalid URI,

Test only changes don't need relman review. :)
Attachment #8798471 - Flags: approval-mozilla-beta?
Attachment #8798471 - Flags: approval-mozilla-aurora?
Whiteboard: [test disabled on Linux e10s] → [checkin-needed-aurora][checkin-needed-beta]

Comment 78

2 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-aurora/rev/8964f57e6bd5
status-firefox51: affected → fixed
Whiteboard: [checkin-needed-aurora][checkin-needed-beta] → [checkin-needed-beta]

Comment 79

2 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-beta/rev/0d849c4393fe
status-firefox50: affected → fixed
Whiteboard: [checkin-needed-beta]
You need to log in before you can comment on or make changes to this bug.