1531818 - Breakage: Redfin.com property search

Status: RESOLVED FIXED

(Core :: Privacy: Anti-Tracking, defect)

Description

[Tony Cinotto [:tcinotto] (UTC-8)]

Visit redfin.com on nightly 67 with "standard" content blocking enabled and try to search for a property or enter your email address, it won't let you until you disable content blocking for the site. See example video: https://drive.google.com/file/d/1HscPt82Fk5daZ-lakQYb5-GV0nzUbdJ_/view?usp=sharing

Comment 1

[(no longer active)]

This is caused by the strict list.

STR:

1. Make a new profile.
2. Log in to https://accounts.google.com.
3. Go to https://www.redfin.com and try to focus a search box.

Comment 2

[(no longer active)]

Here is what is happening here.

The key is this message that gets logged to the console:

The resource from “https://accounts.google.com/ServiceLogin?passive=1209600&osid=1&continue=https://smartlock.google.com/client?callback%3DonGoogleYoloLoad&followup=https://smartlock.google.com/client?callback%3DonGoogleYoloLoad&authuser=0” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).

If you load the URL mentioned in this resource without cookies, the response it will send you will be a text/html response which is the Google Login page. If you load it with cookies, the response will be an HTTP 302 response with a Location: https://smartlock.google.com/client?callback=onGoogleYoloLoad&pli=1 header which will send you to a response with content-type application/javascript; charset=utf-8.

The MIME-type rules used here can consume the latter but not the former. Therefore we receive a JS exception from the network load, which means the initialization of the page will get abandoned and a disabled attribute will not get cleared from the input elements behind the search boxes, so the search boxes will not be usable.

Comment 3

[(no longer active)]

BTW this can happen on any browser with 3rd party cookies disabled. Perhaps we should reach out to redfin.com?

Comment 4

[Peter Saint-Andre [:stpeter]]

I sent a note to Redfin about this.

Comment 5

[Dylan Forbes]

I'm the Redfin dev handling this. It looks like the site works correctly on Firefox 68.0a1. Is 67 going to be released at any point, or will it skip to 68?

Comment 6

[Peter Saint-Andre [:stpeter]]

Hi Dylan, thanks for checking in. Clearly you are using our Nightly channel. Although we love you Nightly users, you're not representative of Firefox users as a whole, most of whom are migrating from 65 to 66 right now. 67 will be released to the general population around May 19th, and 68 will be released in early July. https://wiki.mozilla.org/Release_Management/Calendar has the details. It's up to you whether you want to wait that long, of course. :-)

Comment 7

[Dylan Forbes]

That's just the information I needed. I'll start looking into a fix for Redfin. Thanks a bunch!

Comment 8

[Dylan Forbes]

You say that this can happen in any browser with third-party cookies disabled, but that doesn't seem to be the case. Things work just fine on Chrome with that setting (it changes how we have to handle Google OAuth, but that's it). So I'm not quite sure how to go about fixing this. Could you help guide me in the right direction? Thanks.

Comment 9

[Dylan Forbes]

Ok this is weird, but things seem to be working now. I didn't update the version I'm using, but Redfin doesn't break on Firefox 67 anymore. Did something change server-side? I did see the new ticket but I can't tell if anyone has started working on it.

Comment 10

[Dylan Forbes]

Ah, it looks like the request to Google when sent without their cookies now returns a 200. I suppose that fixed it?

Comment 11

[Johann Hofmann [:johannh]]

Hi Dylan, apologies for the confusion. We used this issue for testing a temporary workaround (bug 1536898) that is designed for quick last-resort type of fixes.

We will remove the test entry (it's more meant for release Firefox) and things will be back to broken again in 24 hours. Unfortunately it's not super easy to circumvent our fix, one approach could be making a new profile and quickly overwriting the services.settings.server pref with e.g. an empty string.

I hope this didn't waste too much of your time.

Comment 12

[Dylan Forbes]

I created a new profile, set services.settings.server to an empty string, and restarted the application (version 67.04b), and redfin.com still works.

Comment 13

[Dylan Forbes]

Also, I'm still not sure how to go about fixing redfin.com, as the issue only happened with Firefox and not Chrome with 3rd-party cookies disabled. Could you elaborate on what exactly I should look into?

Comment 14

[Dylan Forbes]

Pinging again on this. The deadline is approaching!

Comment 15

[Johann Hofmann [:johannh]]

Hi Dylan, sorry for the delay

Our experimental workaround was very short-lived and should no longer be active (https://bugzilla.mozilla.org/show_bug.cgi?id=1536898#c2).

When I make a new profile, I can still reproduce this bug.

I'm really not sure why, but in Chrome smartlock.google.com is loaded directly, without re-routing through accounts.google.com. Quite mysterious.

In any case, the fix to this should probably be clearing the disabled attribute independent of whether that script loaded successfully or not.

Comment 16

[Dylan Forbes]

Alright, I merged a fix (to redfin.com). It seems to be working now. If someone wants to verify for themselves, hopefully they can close the ticket.

Comment 17

[Johann Hofmann [:johannh]]

Can confirm it works now, thank you for the help!