Treeherder Bug Filer Reporter
	Description • 8 years ago
treeherder

Filed by: philringnalda [at] gmail.com

https://treeherder.mozilla.org/logviewer.html#?job_id=7535328&repo=autoland

https://queue.taskcluster.net/v1/task/Z--GnCHMS5WdBmbeadqWDw/runs/0/artifacts/public/logs/live_backing.log

	Henrik Skupin [:whimboo][⌚️UTC+1]
	Comment 1 • 8 years ago

Most likely a networking issue loading the target page when clicking the ignoreWarningButton.

	Henrik Skupin [:whimboo][⌚️UTC+1]
	Comment 3 • 8 years ago

The situation should be better now given that we bumped the timeout for page load from 30s to 300s (as part of the webdriver spec) on bug

	Henrik Skupin [:whimboo][⌚️UTC+1]
	Comment 5 • 7 years ago

The problem here is an outage of itisatrap.org. I see two possible changes here:

1) Don't use the external site if possible (is there a pref to modify it to a local page) when clicking the ignore warning button.

2) Since `click` can now wait for page load (bug 1335778) we could rely on it, to get rid of the long wait time of 300s, because it would return after 5s with no page load detected.

Francois, do you have some feedback to me?

Also one thing to note is that the current page load implementation doesn't raise an error if the navigation ended up in a 404, or 500 like in this case. Andreas, is that something we should do?

	Andreas Tolfsen ❲:ato❳
	Comment 6 • 7 years ago

(In reply to Henrik Skupin (:whimboo) from comment #5)
> The problem here is an outage of itisatrap.org. I see two possible changes
> here:
> 
> 1) Don't use the external site if possible (is there a pref to modify it to
> a local page) when clicking the ignore warning button.

We should absolutely not be using an external site in automation.  I would
consider it a bug if there is not a preference to change where you are
redirected when clicking this button.

> Also one thing to note is that the current page load implementation doesn't
> raise an error if the navigation ended up in a 404, or 500 like in this
> case. Andreas, is that something we should do?

The expected behaviour is described in
https://w3c.github.io/webdriver/webdriver-spec.html#dfn-post-navigation-checks.

In other words, we should not return errors when hitting a 404 or 500.

	François Marier [:francois]
	Comment 8 • 7 years ago

(In reply to Henrik Skupin (:whimboo) from comment #5)
> 1) Don't use the external site if possible (is there a pref to modify it to
> a local page) when clicking the ignore warning button.

There's no pref to control that URL. It's hardcoded: https://searchfox.org/mozilla-central/rev/d441cb24482c2e5448accaf07379445059937080/toolkit/components/url-classifier/SafeBrowsing.jsm#378

(In reply to Andreas Tolfsen ‹:ato› from comment #6)
> We should absolutely not be using an external site in automation.  I would
> consider it a bug if there is not a preference to change where you are
> redirected when clicking this button.

You're not really redirected to a URL. Instead you're allowed to proceed to the original URL you were going to before we showed the interstitial warning page.

Can we redirect the itisatrap.org domain to a local webserver while we run the tests?

	Henrik Skupin [:whimboo][⌚️UTC+1]
	Comment 9 • 7 years ago

(In reply to François Marier [:francois] from comment #8)
> Can we redirect the itisatrap.org domain to a local webserver while we run
> the tests?

But the entries in the safebrowsing database are hard-coded for itisatrap.org, so it won't work for locally served data. Or am I wrong on this part?

	François Marier [:francois]
	Comment 10 • 7 years ago

(In reply to Henrik Skupin (:whimboo) from comment #9)
> But the entries in the safebrowsing database are hard-coded for
> itisatrap.org, so it won't work for locally served data. Or am I wrong on
> this part?

The redirection I had in mind was at the DNS / hosts file level. i.e. making itisatrap.org resolve to 127.0.0.1

	Henrik Skupin [:whimboo][⌚️UTC+1]
	Comment 11 • 7 years ago

Sadly we don't have an easy way to do that. But do you have any hints in case other test harnesses are doing that already?

	François Marier [:francois]
	Comment 12 • 7 years ago

(In reply to Henrik Skupin (:whimboo) from comment #11)
> Sadly we don't have an easy way to do that. But do you have any hints in
> case other test harnesses are doing that already?

If we had a harness that could "redirect" that domain to 127.0.0.1, then it would just work.

Since we don't have that and there isn't an easy pref to change the hard-coded entries, we could either continue to rely on itisatrap.org (which in theory should be reliable since it's just a static site) or maybe move it to a QA-hosted server?

	Henrik Skupin [:whimboo][⌚️UTC+1]
	Comment 13 • 7 years ago

We have mozqa.com, which serves all of our test files. Several other projects make also use of it. In any case it would be a remote connection, so I don't think it will be much better than the current situation.

	Henrik Skupin [:whimboo][⌚️UTC+1]
	Comment 14 • 7 years ago

Lets keep this bug open given that it will only fail if there is an outage of itisatrap.org.