Open Bug 1754152 Opened 3 years ago Updated 3 years ago

document.<formname>.submit doesn't work after innerhtml on table

Categories

(Core :: DOM: Core & HTML, defect, P5)

78 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: created4el, Unassigned)

Details

Attachments

(1 file)

Attached file firefoxbug.php

Steps to reproduce:

my submit javascript:
function cancelOp() {

    alert("ok... cancel...")  ;
    document.adminSession_form.submit();
    alert("ok... cancel should have submitted...")  ;
    return true ;
}

The button that executes that code:
<input type="button" name="cancel" value="Cancel" onclick="return cancelOp()">

The other part of my script changes a table of inputs...
it is pretty long but here are the essentials...

var $tableData = tableData2Array(cmd) ;
document.getElementById("gscrows").value = $new_numrows ;
$newTableString = array2GSCTable($tableData, $new_numrows) ;
document.getElementById("GradeCapacities").innerHTML = $newTableString ;

where "array2GSCTable" creates essentially a table with several rows and 3 columns of <input type="number">

I created a test case at https://alice.samcamp.org/firefoxbug.php

It works with brave but I get unexpected results with firefox.

Actual results:

If I open the page and only change the values of the inputs, then it submits. When I add rows to my table then the code in the "cancelOp" function doesn't work. When it works, only the alert before the submit appears. But after adding the row, the alert after the submit also appears when it shouldn't.

This code works in other browsers like chrome and brave. The code to add rows to the table works. And, as mentioned, even the code to do this "cancel" operation executes the lines as they are very basic where those lines worked before adding the rows of inputs to the table but doesn't after adding them.

What is really strange is I have nearly identical code except instead of modifying a table, I only modify a select button and that one works fine.

After creating this test case, one thing I noticed is that a hidden input that I use to set the number of table rows was modified upon loading the page. I set the value of the input to "1" but when I look at the value of gscrows after loading the page, it is set to two. I can only surmise that somehow the javascript is incrementing it or something whereas the other hidden input I added in, called "ummm", is not modified. And this is what is causing the javascript to break.

After further investigation, the gscrows was set to 2 if I didn't shift-reload the page. Then it was set correctly to 1. And then after clicking on the add rows icon, the cancel op stopped working.

Expected results:

The code should submit the page and execute the cancel operation and go back to another page when I push the "cancel" button whether I add a row or not.

note: I didn't include my browser's user agent string because I am reporting this from a different browser and computer than the one experiencing the issue. But I am using firefox on Debian Linux version 10.11 with fireforx version 78.15.Oesr (64-bit) and also firefox version 91.5.Oesr (64-bit) on a different system which is also running Debian Linux 10.11.

Also, note I tried to upload two files to create my test case but this only allowed me to include one. This file started as a php file but I have edited it to remove the php statements to get rid of my site specific data. The response file was just for the page to go somewhere where I can know it wasn't just staying in one place. I included this file in case you didn't want to go to my test server, alice.samcamp.org.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core

Can you please state in a short sentence what exactly is expected and doesn't work? Both "Save Grade Capacities" and "Cancel" buttons always work for me, they submit and show 2 alerts.

When navigating back to the page we restore form data (as seen in the number inputs). That also restores values in hidden fields, meaning that the gscrows field will contain whatever number of rows was added before submitting, yet the page only adds one row in the table. That will cause exceptions in the doAddRemRow function, so the AddGSCRow button then just executes its default action (submitting).

Severity: -- → S4
Flags: needinfo?(created4el)
Priority: -- → P5

I am using firefox version 91.5.0esr (64-bit) on a Debian Linux platform. If you are using later then perhaps that is good news?

When I do press the "+" to add a row then press the cancel button, then nothing happens. This should not be the case.
When I don't press the "+" then the cancel operation progresses to the second response page as it should.

When I got the javascript error, I did a refresh page before attempting to add a row. When I do this in Chrome, there is no problem with the stale value in gscrows. But in order for firefox to get the right answer, I have to shift-refresh the page. That was not my main purpose in submitting this bug report but just something I observed while trying to create this test case. Then again, it seemed annoying that Chrome would get the right answer when I thought I refreshed the page when apparently it wasn't as refreshed as I thought it was.

Flags: needinfo?(created4el)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: