SUMMING UP:
Test there is no confusion brought by the physical kb being different from the selected layout (see below); if no:
Fully identify your problematic layout (so that I can test) or test yourself one of my keyboards mentioned below and tell if affected by your problem; if they are affected, than it's a Chrome-on-Gnome problem, and we'll continue from there (fix Chrome? fix Gnome?)
Imagining we have no other solution, you have to chose between disabling ALTGR as 3rd level key (possibly enabling a different one) and changing to another kb layout not affected by the problem when navigating with Chrome.
Anyway, your question title in its initial form (How can I make AltGr behave as regular Alt in specific situations?) cannot receive a solution, it is far too general, it should be more like "Chrome AltGr-Arrows shortcuts not working in Gnome with some layouts".
UPDATE (read the rest only after having considered this):
Looking closely I see that your selected layout has AltGr where the physical one has CTRL, but also that the selected layout has another key for 3rd level, which on the physical is AltGr. How could that not be a problem? How does that work? When you say Altgr you are referring to what key? (the physical one on which is written CTRL or that on which is written ALTGR? are both acting as ALTGR?)
All this is getting very confusing and — if you expect an answer (and more effort from others) you should clarify basic things like this.
Only after clarifying the above continuing with the rest could make sense.
This answer should be considered a temporary one - with parts that would have fit a comment, but I find it easier for now (I'll edit accordingly) to post them here.
It seems that Chrome (unlike Firefox) should be able to detect whether a typing field (where special characters can be used) is selected or not. (Testing with different keyboard layouts, including two German ones —'German-Dead acute' and 'German(language)-English(layout)-International with AltGr dead keys'— I can confirm that AltGr in Chrome is reserved as a modifier for typing special characters like those you mention (and thus is not working with arrows) BUT ONLY when a typing field is selected, and that otherwise it can be used as normal Alt.)
What the browser does is reserve the third-level key, which by default is AltGr, when that key is required by the kb-layout. But that doesn't affect the default shortcut on my system: I haven't yet found a layout to replicate your problem.
We must first identify the problem: is it layout-specific, or is it (your) Chrome and/or system specific?
You have to check if indeed Chrome has that problem with all layouts that involve AltGr as 3rd level modifier or not. (For that you could try one of my layouts that qualify but that do not trigger the problem on my system: English US International with dead keys, French (French), Romanian standard. (That because I am still not able to get from you the exact layout that you use now!)
If with those layouts you still have the problem, then we will know for certain that your problem is either with your system or your Chrome version. (I don't think Chrome version is the problem.)
Anyway, for practical purposes yours is similar (even duplicate) to my Firefox question linked above, and the answer cannot be very different:
AltGr can become totally equal to Alt by selecting Right Alt key never chooses 3rd level under Key to choose 3rd level - example for KDE here, for Gnome here, and thus it is not reserved anymore, and the AltGr-Arrow (to navigate history) should work with any kb-layout.
In order to introduce a third-level key as an alternative to AltGr, after selecting Right Alt key never chooses 3rd level
, you can select a new key to chose the 3rd level
, and use that instead of AltGr to type special characters in the problematic kb-layout. (The problem with this solution is that the new 3rd level key loses its other uses as modifier (for example on this website Ctrl+L=hyperlink
or Ctrl+K=code
on selected text stop working with Right_Ctrl if that is selected as 3rd level selector, while Left_Ctrl works.) So, we should look for a less important key that could replace Altgr. I have selected CapsLock, and do uppercase with shift+key.)
The problem with this question is that it's still far too general. You say specific situations in general when in fact it's about AltGr-Arrow shortcut in Chrome. That should be the question: not about all situations, but about Chrome and specifically about the fact that default shortcuts stop working with 3rd level AltGr in Chrome, just like (in my case) in Firefox. In this sense yours looks like a duplicate of my question, except it's about Chrome and not Firefox. You may not like the answer under my question but if indeed Chrome is affected by the same problem you may have no other choice.
I cannot imagine a generic solution where the user would have a way to switch rapidly between the two different statuses of AltGr (as 3rd level modifier or not), other than the one in settings, and even then it would be very cumbersome. (What could that be? A shortcut to toggle the possibility of another shortcut?) That is not the problem. On all the systems that I have been able to test (Kubuntu 20.04 and 22.04, Linux Mint Xfce 20 and Windows 10) Google Chrome is keeping AltGr as 3rd level key without disabling the default shortcut to navigate history.
The mystery for me is still why Chrome acts differently on your system. In order to get close to that we have to rule out the layout as the culprit.
German-Dead Acute
, which can type AltGR+q=@ without disabling AltGr+Left/RightArrow=Back/Forward.