OK, so spent a rainy Saturday morning here in the UK reflashing my phone (XA2) to SFOS 4.0.1.48 as I undertook to @gabrielg to do. At least I didn’t have to go through all the bootloader unlocking process, this being the 3rd or 4th time the phone has been flashed with Sailfish. So, all I had was exactly what is in the Koli SF image - no other apps, no android apps, no accounts configured, nothing in the browser cache, etc … and I still have the same problem with the dialog boxes on the same sites. There is some variation - sometimes I can get a website that didn’t work to work by using Private Browsing, others I can get to work by repeatedly clicking on the main window and then the dialog, and then the main window, and then the dialog, others by clicking ‘Accept’ (or whatever the dialog box requires) maybe a dozen or more times. The only common-sense conclusion I can come to after all this effort is that there is a problem in the Sailfish browser in this respect in the way it handles dialog boxes (surely the only other alternative would be that I have a hardware problem on my phone - perhaps with the capacitive touch screen - but this hardly seems likely as everything else works OK and I am not the only person to experience this problem). The big disappointment for me is that, after configuring my dropbox account, for some reason Sailfish could not find the backup I’d made before reflashing so I had to recover everything manually 
Device: Xperia 10 ii with 4.3
This is my first visit to this thread. I don’t use my phone for browsing generally, I use my PC, but on odd occasions I may look something up using my Xperia 10 ii if I am out and about.
I had a look at 3 sites mentioned here, both in normal mode and private browsing mode. The 3 sites being; washingtonpost | ookla | toodledo
Only Ookla presented me with a consent dialog, which at first was blocked a little by the URL bar, a little scroll up of the screen and I could then tap on the [Consent] button.
No pop ups, no obscured dialogues, no problems at all really. It would be a nice thing to not have to mess with centering/moving the page up just to get a dialogue/pop up. But for me, I accept it as it stands.
My settings for permissions in sailfish browser are as follows;
location: ask
pop-up: block
cookies: allow
camera: ask
microphone: ask
Also, I have ‘Do not track’ enabled on browsers main settings page.
As far as I can tell, this issue was fixed in 4.3. Certainly on web sites that had this problem on 4.2 and earlier now work for me on 4.3 without problem in the web browser.
Since you are on 4.3, that probably explains why you can’t reproduce the bug.
However the problem still exists in native apps with built in webview functionality, so maybe these still use Webkit rather than Gecko, so didn’t benefit from the fix - or maybe there is something else at work in these apps.
There is now a qml component to use Gecko for the WebView. Maybe those apps somehow use the old WebView and it would benefit porting them? Having a list of apps with that issue would probably be good!
The app I mostly see this on is Kactus - which I use for all my rss news feeds.
I think the issue is not soo much the Jolla Sailfish Browser but the Firefox base that is used for it :
In the past older versions of Firefox for Android showed the same issue! 
Another possible issue could be the fact that the whole Internet seems to have gone all “Internet Explorer 6.0 v2” and everyone is building websites that only work properly in combination with Chromium/Google Chrome and probably Microsoft Edge too! 
So @Steve_Everett : I feel your pain! 