Chromium browser problem Options

[CharlesEF]

Hi All,

I'm facing a problem with my 2 Chromium browsers. Firefox displays calendar.php and sample.php with no problems, code does what is expected.

However, my Chromium browsers have a problem . As the code is now calendar.php has the problem, sample.php does not. The problem is in the 'currentYear' field. If you load calendar.php it will load with December 2021 displayed. Change the year to 2022 and press Enter. The calendar will show December 2021 again. Any year you enter will come back 1 year less. The reason for this is that when I press Enter my Chromium browsers will send a 'prevYear' button click, so 1 year gets subtracted.

I can change this behavior simply by changing the order of 2 thead rows. Place the row with id=shead to the top and the 'currentYear' problem now happens in sample.php, only it's the 'prevMonth' button click that gets sent so the 'currentMonth' get subtracted.

So it seems my Chromium browsers sends the left most button as clicked, but I pressed Enter. Could this be a Chromium bug? Or maybe I've overlooked something. Both pages validate with no errors or warnings.

I've looked at this problem for a couple of days so maybe I can't see the problem anymore. I guess I need some extra eyes to look things over?


Thanks for any help,

Charles
 claendar1.zip ( 137.75k ) Number of downloads: 252

[CharlesEF]

I forgot to say I have tried using actual buttons instead of the input buttons I now use. The same problem occurs. I have used the same name for the buttons but different id's. As I understand it multiple buttons can have the same name and the pages do validate 100%.

But, I did find that if you change the year and then tab or click outside of the field then it works correctly. When you tab a javascript submit occurs. When you press Enter a standard submit occurs.

[Brian Chandler]

I don't see how this is a server side problem - php does not know what browser it is generating the files for. Can you give us a link to a demo page with the problem bit on it?

[nootkan]

I can confirm I get the same problem as you when changing the date and hitting enter but everything works fine using the back and forward buttons.

Not sure if this is a bug with Chrome but when I looked at your calendar.php page using the Devtools inspect tool in chrome I see this under the issues tab:

Audit usage of navigator.userAgent, navigator.appVersion, and navigator.platform
A page or script is accessing at least one of navigator.userAgent, navigator.appVersion, and navigator.platform. Starting in Chrome 101, the amount of information available in the User Agent string will be reduced.
To fix this issue, replace the usage of navigator.userAgent, navigator.appVersion, and navigator.platform with feature detection, progressive enhancement, or migrate to navigator.userAgentData.
Note that for performance reasons, only the first access to one of the properties is shown.
1 source
common.min.js:1
Learn more: User-Agent String Reduction

This post has been edited by nootkan: Dec 24 2021, 02:21 PM

[CharlesEF]

I don't see how this is a server side problem - php does not know what browser it is generating the files for. Can you give us a link to a demo page with the problem bit on it?

The attachment has everything you need to see the problem in action.

[CharlesEF]

I can confirm I get the same problem as you when changing the date and hitting enter but everything works fine using the back and forward buttons.

Not sure if this is a bug with Chrome but when I looked at your calendar.php page using the Devtools inspect tool in chrome I see this under the issues tab:

Audit usage of navigator.userAgent, navigator.appVersion, and navigator.platform
A page or script is accessing at least one of navigator.userAgent, navigator.appVersion, and navigator.platform. Starting in Chrome 101, the amount of information available in the User Agent string will be reduced.
To fix this issue, replace the usage of navigator.userAgent, navigator.appVersion, and navigator.platform with feature detection, progressive enhancement, or migrate to navigator.userAgentData.
Note that for performance reasons, only the first access to one of the properties is shown.
1 source
common.min.js:1
Learn more: User-Agent String Reduction

Strange, since I don't use any 'navigator.userAgent' commands. I'll look into it, thanks.

[CharlesEF]

I find that if I put an alert in the 'onSubmit()' function then it works correctly. As the first line in the function place 'alert("");'. Now load calendar.php and change the year and press Enter twice. For me the page works correctly now. This means that the Chromium browsers are not sending the errant button click. But, of course, this is not a fix for my problem.

This leads me to think that this is a Chromium bug. To get around it I will just go back to using an event listener for the 'currertYear' field.

[Christian J]

I find that if I put an alert in the 'onSubmit()' function then it works correctly.

I haven't had time to test the scripts properly, but when such alerts have fixed things for me it's sometimes been due to some script instruction running before everything before was ready. Note that the DOMContentLoaded event doesn't wait for external files, use load in order to wait for everything. I don't know if/what the difference is between document.addEventListener("DOMContentLoaded" and window.addEventListener("DOMContentLoaded".

I also saw a function named "onResize()", which is also the reserved name of an event. Not sure if that could trig bugs? Personally I once ran into trouble for naming a function "open()", which of course is also the name of a method...

[CharlesEF]

As far as I know 'onresize' is not a reserved word. But, I did change the name and I used 'load' instead of 'DOMContentLoaded'. Made no difference, problem persists.

I have reported this problem to the Chromium team. Waiting to hear from them now.

[Christian J]

script instruction running before everything before was ready.

Here's one potential case:

CODE

  onResize();
  if(!document.getElementById("currentYear1").disabled)

Above, maybe the IF condition is evaluated before the onResize() function has finished running? The function does indeed seem to change the DISABLED state here:

CODE

document.getElementById("currentYear1").disabled = false;

Try putting the IF condition inside the onResize() function to ensure the correct order of things.

[CharlesEF]

Here's one potential case:

CODE

  onResize();
  if(!document.getElementById("currentYear1").disabled)

Above, maybe the IF condition is evaluated before the onResize() function has finished running? The function does indeed seem to change the DISABLED state here:

CODE

document.getElementById("currentYear1").disabled = false;

Try putting the IF condition inside the onResize() function to ensure the correct order of things.

Well, the onResize() function doesn't need the itm variable. But I moved it anyway and I still have the same problem. I still don't see any reason why a 'Previous Year' button click is sent to the server when I press 'Enter' in the form input. Firefox doesn't do this.

[Christian J]

I still don't see any reason why a 'Previous Year' button click is sent to the server when I press 'Enter' in the form input. Firefox doesn't do this.

I wasn't paying attention and missed the above, sorry!

Pressing the Enter key may indeed submit forms (if there's no TEXTAREA). I made a test form with two Submit buttons:

CODE

<form name="test">
<input type="text" name="" value="">
<input type="submit" name="foo" value="Foo">
<input type="submit" name="bar" value="Bar">
</form>

and when pressing Enter the first Submit button's NAME/VALUE pair is sent in both Firefox and Vivaldi.

Since Previous Year is your form's first Submit button, the behavior you describe makes sense. Rather it's strange that it doesn't happen in Firefox too. I still haven't run the scripts in a browser, but it seems the javascript disables the buttons in narrow windows.

[pandy]

Pressing the Enter key may indeed submit forms (if there's no TEXTAREA). I made a test form with two Submit buttons:

And only one input type text. IIRC browsers weren't consistent about this and probably still aren't.

At least there was a thought behind it in the beginning...
http://web.archive.org/web/20060518010241/...rmquestion.html

[CharlesEF]

In the thead section of calendar.php there are 3 rows, 2 UI (user interface) rows and the DOW row. By default, the 2nd UI row (id=shead) has all children disabled and the row hidden. When the window size get down to 225px wide then the onResize() function disables everything on the 1st UI row and hides the row while the 2nd UI row is enabled and shown.

If you place the 1st UI row (id=nhead) below the 2nd UI row you will find that the errant button click has moved to sample.php while calendar.php now works correctly. Strange!

[CharlesEF]

I should add that I already have a workaround for this problem. I don't see any reason why an errant button click is sent to the server. I don't think it has anything to do with my code or HTML.

I have looked at this for so long that I posted it here in hopes of someone else seeing something I may have missed.

[CharlesEF]

Pressing the Enter key may indeed submit forms (if there's no TEXTAREA). I made a test form with two Submit buttons:

And only one input type text. IIRC browsers weren't consistent about this and probably still aren't.

At least there was a thought behind it in the beginning...
http://web.archive.org/web/20060518010241/...rmquestion.html

Strange, as far back as I can remember pressing Enter in a form input caused the form to submit.

[CharlesEF]

After digesting Pandy's link and Christian J's test page I came to the conclusion that all I needed where 2 hidden submit buttons. I don't test for those buttons so the problem is no more.

I'm still testing but this might be a better way.