There are others on this forum who have experienced the same problem with other websites on the latest Gecko 60 version of the native browser and, whilst no doubt you are right that other platforms also suffer other web page rendering issues with their browsers, I can’t really see why “well similar things happen on other platforms so its ok that it happens on Sailfish” is a very good justification for doing nothing. You are of course entitled to your opinion that it is not a bug, but does that mean that I am not entitled to my opinion that it is? That is a rhetorical question on my part and does not need a reply.
2 Likes
Agreed, this does not work either …
www.toodledo.com is working for me.
But, I have the same problem by visiting site https://www.speedtest.net/ . It is impossible to clik Accept and to proceed.
BTW: how to start private mode in the recent version?
Good question: where to find private mode. I looked in browser setting and noticed that Permissions - Pop-up setting was Block. When I set it to Allow I was able to accept a cookie pop-up that I couldn’t this morning…
Its very tortuous to access. Open the browser and then open any website in normal mode you like. You have to open a normal website before you can access private browsing (this seems to be a UI ‘bug’). Once a website is open tap on the tab icon on the bottom bar (the square icon with the number inside) to get the list of open tabs. Then use the pulley menu at the top. Pull it down until you see ‘Private browsing’ select this and you will get a new private browsing tab.
1 Like
Interesting that toodledo works for you but speedtest does not. I needed to access an article from the Washington Post this morning for work, so I loaded the website washingtonpost.com and clicked on ‘Browse’ which allows you to access a limited number of free articles before you have to subscribe. You then get presented with the cookie dialog box where you have to check a tickbox ‘Accept’ and then press a button to continue. I found it was not possible to check the tickbox no matter how many times I tried. I also tried tapping the background window and then tapping the tickbox to see if the change in focus registered, but it didn’t. I gave up and used my iPhone instead. However, to make sure I’d got the sequence right to write up in this post I went through the whole thing again … and about the fourth or fifth tap on the tickbox it actually worked this time … but toodledo still doesn’t work for me, nor does the weather channel site posted by @peterleinchen above. No consistency here!
Before anyone asks …yes I do have pop-ups allowed in the browser settings 
No the issue has always been present and affects many websites. Ok actually it works for the given website, but fails on many others. Often the “Accept” button ends up working when you click all around, but the “Customize” subpages are often impossible to validate.
1 Like
I really think this bug report has to be altered so that the focus of it is not a site that actually works, except to the person who reported it.
It would be beneficial to collect the sites that don’t work, as we used to do in TJC, but it doesn’t contribute when the bug report itself is misleading.
I don’t think this is a “GDPR bug”, as many sites will implement it differently - it’s just the way Javascript is processed alongside the DOM and whatnot.
@Steve_Everett, I know you’re frustrated, but all I told you is that the report that you opened is not 100% reproducible. Please consider re-doing it in such a way that others can contribute other sites, and accept the fact that your example works for others, and it’s your device that is at fault (or you didn’t mention certain preconditions to reproduce it).
My interest in helping here is depleted, so best of luck.
Maybe, the picture shows more than just words. This was taken in private mode (thank Steve for the explanation) andwith pop-ups allowed.
Oh good heavens 
- OK, just for you … I am definitely seeing this behaviour because my device is at fault, my bug report is therefore incorrect. You are right and I am wrong. I will of course reflash my phone to correct my error as you direct. Happy now?
When it walks like a duck, talks like a duck and looks like a duck … then there is absolutely no way it can actually be a duck …
I assume the issue here is that you cannot scroll the dialog box to actually get to the button in order to press it (even if you could) because the focus has not been raised to the dialog box?
Yes! That’s the point!
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 
1 Like
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.
2 Likes
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.
1 Like
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! 
1 Like