Open lordarcadius opened 4 months ago
Can the bug be reproduced with corresponding Chromium version?
Yes
Are you sure?
Yes
how should I interpret it? In any case, it works for me, it's a big problem not being able to reproduce it.
I am attaching a video to reproduce this issue. Please check.
@uazo I even tried building Chromium myself and the Vanilla Chromium doesn't have this. This issue comes when we merge Cromite or CalyxOS patches. I think some patches are creating this issue. I couldn't figure which ones.
I think it is some limitation imposed by google for no reason. If you change via setting the desktop user agent to
Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
it works without problems. one should ask google directly for explanations, but I don't think they care.
Anyone else noticed the gap between the JavaScript JIT and the Timezone override in Site settings in the video, why is there ?,
I think it is some limitation imposed by google for no reason. If you change via setting the desktop user agent to
Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
it works without problems. one should ask google directly for explanations, but I don't think they care.
This user agent is working because it's not the user agent of a desktop. If you put something like Windows or Linux, you'll get same error. And as I said, this issue occures only after merging your patches. Maybe there is some patch causing this issue.
tried with bromite and even brave, same result, but kiwi works. it is impossible to read the js code of that site, I don't think I can do anything with it.
Maybe there is some patch causing this issue.
if you want to try and work out which one it is, by slowly removing the various patches, rebuild and test, you are welcome! the first one you could try to remove is the client hint (Client-hints-overrides.patch): if you do, tell me and I will assign you the task
tried with bromite and even brave, same result, but kiwi works. it is impossible to read the js code of that site, I don't think I can do anything with it.
Maybe there is some patch causing this issue.
if you want to try and work out which one it is, by slowly removing the various patches, rebuild and test, you are welcome! the first one you could try to remove is the client hint (Client-hints-overrides.patch): if you do, tell me and I will assign you the task
I will let you know about this.
I will let you know about this.
I thought about it, I was wrong. it is a big problem that needs to be addressed and understood. I will try it too.
mainly because it constrains the use of the browser and that is something I do not want. Furthermore, it seems that the time used for adding new features I am working on (such as the platform fido webauth) is lost because, for google, the browser is not secure. @lordarcadius thanks for the report (and for patience)
I will let you know about this.
I thought about it, I was wrong. it is a big problem that needs to be addressed and understood. I will try it too.
mainly because it constrains the use of the browser and that is something I do not want. Furthermore, it seems that the time used for adding new features I am working on (such as the platform fido webauth) is lost because, for google, the browser is not secure. @lordarcadius thanks for the report (and for patience)
Glad to help. I will also try to fix it from my end. Also, I found another issue, Google Meet should work when desktop mode is enabled in Bowser. It fails to even start. It works pretty well in Vanilla.
by changing the useragent from
Mozilla/5.0 (X11; Linux) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
to
Mozilla/5.0 (X11; Linux) AppleWebKit/537.36 (KHTML, like Gecko) Chromium/124.0.0.0 Safari/537.36
^^^^^^
the site allows me to log in. I do not understand whether it is a bug in the algorithm used by google to identify the browser, because, to say that a browser is safe just because the useragent is changes seems like a joke to me.
by changing the useragent from
Mozilla/5.0 (X11; Linux) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
to
Mozilla/5.0 (X11; Linux) AppleWebKit/537.36 (KHTML, like Gecko) Chromium/124.0.0.0 Safari/537.36 ^^^^^^
the site allows me to log in. I do not understand whether it is a bug in the algorithm used by google to identify the browser, because, to say that a browser is safe just because the useragent is changes seems like a joke to me.
Exactly, it sounds stupid if Google is doing it. Maybe we should look more deeply into it.
Exactly, it sounds stupid if Google is doing it.
no, I don't think so, after all, google knows all the secrets of chromium, and if there is that check, it must serve some purpose.
I have come across this bug (https://issues.chromium.org/issues/40390690), concerning the ProcessPerSite
flag. The bug, by the way, listed as fixed, but doesn't actually look fixed to me. all iframes in fact have a mobile useragent in javascript but via network the desktop useragent instead. and this is also common behaviour in brave and kiwi.
I'm investigating to see if somehow that flag has something to do with it.
I am desperately trying to understand the motivation, but it seems to be very complex. I am heartened, however, to realise that google's scary message is perhaps a bit far-fetched. Comparing brave and kiwi (the only ones to provide an x64 version - do you know any others?) the former works, as I would have expected, but the latter should not pass, being in my opinion still at version 115 even though it says it is at version 124. However, I will come back to this issue, first I will close the other bugs.
I am desperately trying to understand the motivation, but it seems to be very complex. I am heartened, however, to realise that google's scary message is perhaps a bit far-fetched. Comparing brave and kiwi (the only ones to provide an x64 version - do you know any others?) the former works, as I would have expected, but the latter should not pass, being in my opinion still at version 115 even though it says it is at version 124. However, I will come back to this issue, first I will close the other bugs.
Sure.
I know it's totally unrelated to this thread, but do you have any idea how URL navigation works in Chromium especially on Java layer. When URL is launched manually in a tab then loadUrl function of NavigationController is called. But which function of which class is called when the user clicks on a link in a webpage? Because NavigationController isn't called on hyperlink clicks.
This is the problem I am facing: https://groups.google.com/a/chromium.org/g/chromium-dev/c/CQ8qV1YWHIY?pli=1
but do you have any idea how URL navigation works in Chromium especially on Java layer
if navigation starts from the user, java informs the browser (which is in native) in the way you described. the other navigations request starts from blink and is forwarded to the browser via mojo inter process calls. I don't remember the flow exactly by heart, but when I fix this I'll tell you.
but do you have any idea how URL navigation works in Chromium especially on Java layer
if navigation starts from the user, java informs the browser (which is in native) in the way you described. the other navigations request starts from blink and is forwarded to the browser via mojo inter process calls. I don't remember the flow exactly by heart, but when I fix this I'll tell you.
Alright, I will wait. But if you can give at least some Java class name which is part of the flow then maybe I can look into the flow myself.
This is the problem I am facing: https://groups.google.com/a/chromium.org/g/chromium-dev/c/CQ8qV1YWHIY?pli=1
ah, if you ask them they surely know more.
I simply want to block the URL and load an Error url like I did in the NavigationControllerImpl class.
but you're missing the point, you have to work on the urlloaders (or on the throttles) for blocking and interstitials to alert the user. the former you can see for example in the adblock patch or in the firewall patch, while for the latter I don't know yet, but I'll have to figure it out with https://github.com/uazo/cromite/issues/171
But if you can give at least some Java class name which is part of the flow
there is no java class, everything is native side.
But if you can give at least some Java class name which is part of the flow
there is no java class, everything is native side.
Okay. Thanks for the help man.
Hi @uazo,
Did you get the chance to look into this issue?
Also, I have something important to discuss with you. Since I have no other method to connect with you, shall we connect over email? Please drop your email or reach out to me at vipul@primeos.in
Preliminary checklist
Can the bug be reproduced with corresponding Chromium version?
Yes
Are you sure?
Yes
Cromite version
123.0.6312.122
Device architecture
arm64
Platform version
Android 14
Android Device model
Samsung Galaxy S23+
Is the device rooted?
No
Changed flags
No flags changed
Is this bug happening in an incognito tab?
No
Is this bug caused by the adblocker?
No
Is this bug a crash?
No
Describe the bug
When you try to Sign in to Google Account and the desktop site is turned on, it says "App or Browser may not be secure" instead of showing password screen.
This doesn't happen in Mobile site though.
Steps to reproduce the bug
Now you will see the error.
Expected behavior
It should let me sign in to my Google account.
Screenshots
Details
![Screenshot_20240419_175250](https://github.com/uazo/cromite/assets/13603567/5f93bd1d-21e8-43e6-b02e-968f2512b404)