1094170 - (e10s) Error 400 on "Why was this page blocked"

Status: VERIFIED FIXED

(Toolkit :: Safe Browsing, defect)

Description

[Gian-Carlo Pascutto [:gcp]]

Current Nightly, e10s enabled.

1) Go to https://www.itisatrap.org/firefox/its-an-attack.html
2) Click "why was this page blocked"

The request goes to:

https://safebrowsing.google.com/safebrowsing/diagnostic?client=Firefox&hl=en-US&site=about:blocked?e=malwareBlocked&u=https%3A//www.itisatrap.org/firefox/its-an-attack.html&s=blacklist&c=UTF-8&f=regular&d=The%20site%20at%20www.itisatrap.org%20has%20been%20reported%20as%20an%20attack%20site%20and%20has%20been%20blocked%20based%20on%20your%20security%20preferences.

This appears to be specific to e10s mode.

Comment 1

[Marco Mucci [:MarcoM]]

Dropping from IT 38.1

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Attachment: Let about:blocked be loaded in the content process. r=?

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8574179 [details] [diff] [review]
Let about:blocked be loaded in the content process. r=?

So I think the problem here is that about:blocked is not allowed to be run in the content process, and so we redirect to the parent.

But about:blocked is this special error page that docshell loads internally (as in, it doesn't update the awesomebar as a location change or anything). When we forward it to the parent process, we pass the full "hidden" URL along (the about:blocked?foobar stuff). None of the UI expects that.

I think the shortest path to success here is allow the about:blocked page to load in the content process. A quick glance at blockedSite.xhtml shows that it doesn't do anything magical or chrome-y, and some smoke-testing shows that this fixes both this bug and bug 1094172.

What do you think, Mossop?

Comment 4

[Dave Townsend [:mossop]]

Comment on attachment 8574179 [details] [diff] [review]
Let about:blocked be loaded in the content process. r=?

Review of attachment 8574179 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Thanks for the quick review!

remote:   https://hg.mozilla.org/integration/fx-team/rev/0ece6a897f47

Comment 6

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/0ece6a897f47

Comment 8

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bugnotes

http://people.mozilla.org/~mconley2/bugnotes/bug-1094170.html

Comment 9

[Nazir Ahmed Sabbir [:NaSb]]

I have reproduced this bug with Nightly 36.0a1 (2014-11-05) on Linux x64 Bit with instruction from comment 0.

Verified as fixed with latest Nightly 41.0a1 (2015-06-02) (Build ID: 20150602055237)

Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0

[bugday-20150603]

Comment 10

[Hossain Al Ikram [:ikram] (QA Contact)]

Reproduced the bug with Nightly 36.0a1 ( 2014-11-05 ) on Windows 7 64 Bit with the comment 0's instruction!

Verified as fixed with Firefox Nightly 41.0a1 (Build ID: 20150602055237) 

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0