1941483 - Accela Government Software - Required Use No Beuno with Firefox. Civic Plus Software Bug Report.

Status: UNCONFIRMED

(Web Compatibility :: Site Reports, enhancement, P2)

Description

[Bryce Mozilla Nesbitt]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36 Edg/131.0.0.0

Steps to reproduce:

I'm a regular user of Firefox, and of various government website required to file or work with building permits. It's not possible to get a permit without using these sites. These sites all require a free login: the problem won't be apparent without a login.

Actual results:

Accela holds the contract for various nearby jurisdictions including:

https://permits.cityofberkeley.info/citizenaccess/Default.aspx
https://aca-prod.accela.com/OAKLAND/Default.aspx

And many others. The product is variously called "Civic Plus"

https://www.accela.com/building/

Expected results:

It's impossible to complete actions using Firefox. The most consistently broken feature is search, where the text boxes needed to finish the work are not visible on Firefox. The Oakland California site has large black bars that obscure needed buttons on top of this.

The sites have remained broken for years, despite multiple reports to the Cities and to Accela software (which says they don't take bug reports directly from the public). Accela has more or less brushed off the Firefox reports. The cities have completely brushed off the Firefox reports. The way Accela products work is they are not a single template: it's more like a script language. As such the software is rarely if ever updated. It's not a cloud service: it runs at the city in question.

As a result I have to switch to MS Edge to complete my work.

Comment 1

[Bryce Mozilla Nesbitt]

Is it possible for Mozilla Foundation to send paper letters, to companies like this, or cities employing companies like
this, with some sort of equity / equality / equal access pitch?

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to Bryce Mozilla Nesbitt from comment #0)

The Oakland California site has large black bars that obscure needed buttons on top of this.

I can reproduce this part without needing an account, by simply visiting the login page. Steps to reproduce:

1. Visit https://aca-prod.accela.com/OAKLAND/Default.aspx
2. Click "Login" at top-right (the right half of the "Register | Login" menu-bar item).
3. Scroll down the page, and look for a "new users" section with a "Register now" Button.

EXPECTED RESULTS: No content clipped or covered up -- should be able to scroll the whole "Sign in" UI.
ACTUAL RESULTS: Much of the sign-in UI is clipped, and I can't scroll to see it.

This content is actually in an iframe which for some reason the site styles like so, in Firefox:

  overflow: hidden;
  height: 580px;

This results in the content (which is taller than 580px) being clipped.

In Chrome, or in Firefox-spoofing-as-Chrome with the "Chrome mask" extension, the site initially loads at 580px tall and then suddenly dynamically increases that height to a larger value (based on some measurement inside the page, presumably).

So:

• At least part of the issue here is user agent sniffing, which is giving Firefox a worse experience (probably by accident, maybe related to some ancient behavioral difference that no longer exists).
• We can work around that using user-agent spoofing.

Bryce: could you install the "Chrome Mask" extension ( https://addons.mozilla.org/en-US/firefox/addon/chrome-mask/ which adds an entry in or next-to the Firefox toolbar extensions puzzle-piece extensions menu); and activate it (toggle its slider to "on" when you're viewing an affected site); and then retest & see how much of the issues remain? Note that its slider is on a per-site basis, so you may need to activate it separately on the two different sites that you linked in comment 0 (for Berkeley and for Oakland).

If that fixes all/most of the issues, then that's something we can take action on by just directly shipping an intervention to pretend to be Chrome on these sites.

Comment 3

[Bryce Mozilla Nesbitt]

---------- Forwarded message ---------
From: Accela User Request <[e-mail]>
Date: Tue, Oct 8, 2024 at 9:30 AM
Subject: RE: Unable to access ACA
To: Bryce Nesbitt
Cc: Accela User Request <[e-mail]>

Good morning Bryce,

I hope you’re doing well. I saw the email thread regarding the issue with Accela Citizen Access (ACA) and learned that you’re unable to access ACA on Firefox.

Based on our experience, Accela performs best with Microsoft Edge and Google Chrome, but it is also compatible with Firefox. Since ACA is cloud-based, I recommend clearing your browser cache and ensuring that cookies for the ACA portal are enabled.

I would like to thank you on bring to our notice for outdated verbiage regarding use of** INTERNET EXPLORER 11** as it is no longer used and has been replaced by Edge.

Please let me know if you continue to experience issues or need further assistance.

Best regards,
Planning & Building Dept.

Comment 4

[Daniel Holbert [:dholbert]]

Thanks for sharing that. It sounds like they're interested in supporting Firefox at least, which is good to hear. :)

Please see my last two paragraphs at the end of comment 2 -- could you try the extension linked there (and toggle the slider when viewing the affected sites) and see if that helps? It does help for me at least on the login page, so I'm eager to know if it helps in all of the affected pieces of this site.

Comment 5

[Daniel Holbert [:dholbert]]

For reference, here's a screencast demonstrating the bug that I'm seeing on the login page discussed in comment 2 (visible at the start of this screencast, at t=0s), and demonstrating that it goes away when I activate Chrome Mask for that site (from t=16s to t=28s), and that it comes back when I deactivate Chrome Mask (t=30s to end):

https://drive.google.com/file/d/14aS_hcyV1L12qa10P1VvhdX17F4gaLah/view?usp=drive_link

Comment 6

[Bryce Mozilla Nesbitt]

So it's much better with the user agent switcher.
I tried both "user agent switcher" and the more cartoon oriented "chrome basic".

These companies all claim that Firefox does not have enough users to support.
I'd like to find a UA that works, but is something other than Chromium based.

Comment 7

[Bryce Mozilla Nesbitt]

Ok, verified.
Both sites are working much better when spoofed as Safari (any version).

Comment 8

[Daniel Holbert [:dholbert]]

So the relevant JS is this function (abbreviated slightly by me to highlight the spots where its logic explicitly diverges based on the browser's UA string and how that impacts the sizing):

    function iframeAutoFit()
    {
[...]
                    if (isSafari()) {
                        h1=ifrm.contentWindow.document.body.scrollHeight;
                    }
[...]
                        if(isFireFox() == false)
                        {
                            if (chk) {
                                h1 = parseInt(h)+60;
                            }
                        
                            ifrm.style.height = ifrm.parentNode.style.height = h1 +"px";
                        }
                        else
                        {
                            if (chk) {
                                if ($.exists(popupDialog)) {
                                    h1 = parseInt(h) + 60;
                                } else {
                                    h1 = ifrm.contentDocument.body.scrollHeight;
                                    h1 = parseInt(h1) + 60;
                                }
                            }
                            
                            ifrm.height = h1;
                        }

That^ JS all lives in the source of the HTML at this URL:
https://aca-prod.accela.com/OAKLAND/login.aspx

(and for reference, isFireFox() is defined as navigator.userAgent.includes("Firefox"); in https://aca-prod.accela.com/OAKLAND/bundles/accela-common )

In the isFireFox()-being-true case, that JS never sets ifrm.style.height, i.e .the iframe's height, so that's why the iframe remains short when we're using our default UA string.

Comment 9

[Daniel Holbert [:dholbert]]

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:

<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:

<iframe id="ACAFrame" [...] style="overflow: hidden; height: 580px;"  [...] height="958">

The height="958" attribute that the site sets there has no effect because theheight: 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.

Comment 10

[Daniel Holbert [:dholbert]]

I reached out to the Oakland site (using the email address from comment 3) to see if they can fix this on their side and/or direct me to the appropriate upstream folks.

Comment 11

[Daniel Holbert [:dholbert]]

Various other potentially-affected deployments can be found by just searching Google for site:https://aca-prod.accela.com/, here:
https://www.google.com/search?client=firefox-b-1-d&q=site%3Ahttps%3A%2F%2Faca-prod.accela.com%2F

I looked at these ones and found the same faulty "isFireFox"-based code snippet that I quoted in comment 8 in all of their login pages:
https://aca-prod.accela.com/MESA/default.aspx
https://aca-prod.accela.com/NAPACO/Default.aspx
https://aca-prod.accela.com/STOCKTON/default.aspx
https://aca-prod.accela.com/PALOALTO/Default.aspx
https://aca-prod.accela.com/ANAHEIM/Default.aspx

So it seems like we do really need to get in touch with the upstream folks at Accela, since this is broader than any one particular city-specific deployment.