Bugzilla

The site's firefox-specific codepath *does* successfully set `ifrm.height` to a large value, but that has no effect because the site still has a smaller value set in the inline style attribute.

i.e. the iframe starts out like this when you load the landing page:
```HTML
<iframe id="ACAFrame" [...] style="overflow: hidden; height: 580px;" [...]>
```
...and when the above-quoted JS runs and sets `ifrm.height` in Firefox, it ends up looking like this:
```HTML
<iframe id="ACAFrame" [...] style="overflow: hidden; height: 580px;"  [...] height="958">
```

The `height="958" attribute that the site sets there has no effect because the `height: 580px` in the style attribute has higher priority.

This may have worked at some point in the past if the site didn't set the `height` in the style attribute.  But they do set it in the `style` attribute today, which trivially breaks their Firefox-specific codepath.

So: I think we can diagnose this as definitely a site bug where they're doing User-Agent sniffing and sending Firefox down a broken path in their logic, unfortunately.  We can work around it with a site-patch (spoofing as Safari or Chrome) and/or by attempting outreach to ask if they can remove that broken Firefox codepath.

The site's firefox-specific codepath *does* successfully set `ifrm.height` to a large value, but that has no effect because the site still has a smaller value set in the inline style attribute.

i.e. the iframe starts out like this when you load the landing page:
```HTML
<iframe id="ACAFrame" [...] style="overflow: hidden; height: 580px;" [...]>
```
...and when the above-quoted JS runs and sets `ifrm.height` in Firefox, it ends up looking like this:
```HTML
<iframe id="ACAFrame" [...] style="overflow: hidden; height: 580px;"  [...] height="958">
```

The `height="958" attribute that the site sets there has no effect because the `height: 580px` in the style attribute has higher priority.

This may have worked at some point in the past if the site didn't set the `height` in the style attribute.  But they do set it in the `style` attribute today, which trivially breaks their Firefox-specific codepath.

So: I think we can diagnose this as definitely a site bug where they're doing User-Agent sniffing and sending Firefox down a broken path in their logic, unfortunately.  We can work around it with a site-patch (spoofing as Safari or Chrome) and/or by attempting outreach to ask if they can remove that broken Firefox-specific codepath.