424698 - [FIX]textbox.setAttribute("value", ...) fails if the textbox has been hidden in the past using display:none

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Alex]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061003 Firefox/2.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061003 Firefox/2.0

I am building a page with javascipt that popups and hides textforms whose values are being changed dynamically with buttons that turn ON/OFF style.display= "block/none'. So I have a problem with FF and other gecko browser like Mozilla and epiphany which remember the values in the form input. Everything works OK except that, when I hide the textform and open it again, new values generated with the buttons I describes earlier are not displayed and stay the same all the time. They are different, the changes are happening on the background, and I can see them, if I save the page and open. They are not displayed in the text inputs while being changed. Bfcache set to 0. Also I tried deleting cache and private data. I tried meta tags with no-cache, no-store. Nothing helps except shift-ctrl-R, but then everything is reloaded and deleted. I don't have such a problem in opera and internet explorer. How can I disable it in FF?

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Jesse Ruderman]

I don't completely understand this bug report.  Can you give a complete set of steps to reproduce along with stating the expected behavior and Firefox's behavior?

Comment 2

[Alex]

Thank you, Jesse, for your reply. Yes, description is confusing. That's why I provided the URL: http://www.3dplumbing.net/tutorials/texgen/

It looks like a cache issue. I am making a page with DHTML. The page will be a huge form to collect data from a user and sent to the server for further processing by the PHP program. So the problem with firefox, mozilla and epiphany is that that they remember the values in the text inputs of the form. For example, if I add the second color bar freshly created (actually it was already there but hidden from a user with style display none), it's OK. I can manipulate the input values dynamically without a problem. But when I hide this color bar with the "remove" button and then open it again, the input values stay the same all the time. They are being changed dynamically on the background with the buttons, but not on the foreground. I can see that, if I save the page and open it in FF, for example. The changes are not displayed in the input fields. The user sees nothing. I need to disable this FF feature, if it's possible, because IE and Opera are OK.

The steps I did were the ones I found like:
1. Bfcache set to 0
2. cleaning cache in the preferences
3. removing private data
4. meta tags with with no-cache, no-store

Nothing helps but shift-ctrl-r ( everything is deleted and reloaded)
What else can I do?
Thanks, Alex.

Comment 3

[Jesse Ruderman]

Here's what I tried:
1. Load http://www.3dplumbing.net/tutorials/texgen/
2. Click "add"
3. In the second row, click the textbox below "#FFFFFF".
4. Type 'a'.
5. Click "remove".
6. Click "add".

In all browsers I tried (Firefox trunk, Safari 3.1, and a recent Opera snapshot), the 'a' I typed was still visible after step 6.

Comment 4

[Alex]

Sure it is visible when it is typed. And that's the problem. The trick is that nothing is needed to be typed at all but changed dynamically with the buttons.
Could you try:
1. Press "add"
2. Press the button with the orange drop.
3. Choose some color on the colorpicker.
4. Move a little rectangle that will appear in the yellow vertical bar with the with "+/-" buttons.
5.Play with "*", "/", "+" and "-" buttons and the other set of "+/-" buttons.
6. Press "remove"
7. Press "add"
8. And now try to repeat steps 2-5.

Everything is seen very well, but nothing changes. No, the changes are happening on the background in the browser's memory. If you save the file and open it again in another window, you will see that data is different. But before a user's eyes nothing is going.
How to fix?

Comment 5

[Jesse Ruderman]

Ok, I think I see what you're talking about now.

Steps to reproduce:
1. Click "add".
2. Click the button with the orange drop and select a color.
     Notice that the textbox changes to reflect the color you picked.
3. Click "remove".
4. Click "add".
5. Click the button with the orange drop and select another color.

Result: the textbox doesn't change to reflect the second color picked.

Comment 6

[Jesse Ruderman]

Attachment: simple testcase

Comment 7

[Jesse Ruderman]

The workaround is to use 
  textbox.value = ...
instead of 
  .setAttribute("value", ...)
in colorpicker.js.

Comment 8

[Jesse Ruderman]

Related to bug 184732?

Comment 9

[Boris Zbarsky [:bzbarsky]]

Somewhat, but that bug is a vague uselesness-fest, so all sorts of stuff could be related to it.

This bug is simply due to the fact that nsHTMLInputElement::TakeTextFrameValue calls SetValueChanged(PR_TRUE).  I don't think it should be doing that.

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Here is what I suspect happens:

1. The node keeps an internal flag, has-.value-ever-been-changed. This is
   initially set to FALSE
2. While this is false calling setAttribute("value") changes .value
3. The value of the form can live in two places, the frame or the node
4. When you set display:none we kill the frame.
5. Killing the frame makes the frame push its value into the node to make the
   node own the value.
6. This pushing causes the has-.value-ever-been-changed flag to be set to TRUE.
7. Calling setAttribute("value") no longer changes .value.

The problem here is in step 6. This pushing should not be done in such a way that we change the flag.

Not a blocker, but would be nice to have fixed for sure.

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Agree with comment 9. On all accounts :)

Is SetValueChanged call as soon as the textframe value is modified. It really should. If so removing the call in TakeTextFrameValue sounds like the right fix.

Comment 12

[Boris Zbarsky [:bzbarsky]]

SetValueChanged() is called by the edit action listener in the textframe (which also fires oninput, etc).  So yes, it should be called as soon as the user types in the frame.

Of course any patch for this bug would mochitest all that.

Comment 13

[Alex]

Thank, guys, for your help. I tried textbox.value = ... It really eliminates the problem I described above. The other issue appears that the new data cannot be saved and reused at a later time. I am not very experiences in DHTML and not sure if this new value will be passed into PHP. I will let you know as soon as I finish the interface.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix

Comment 15

[Boris Zbarsky [:bzbarsky]]

Fixed.  I fixed this for textarea as well.