readonly text fields are not readonly

VERIFIED FIXED in M17

Status

()

Core
Layout
P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: Stephen P. Morse, Assigned: kinmoz)

Tracking

({regression})

Trunk
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+]Fix checked in.)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
Collect at least one cookie from somewhere

Go to cookie viewer.  The cookie should be displayed (due to bug 43201 you won't 
see the cookies until you force a redraw by covering with another window and 
then uncovering).

Click on one of the cookies.  Its properties should now be displayed.  They 
aren't.  Even forcing a redraw does not bring up the display of the 
properties.

(This has been broken out of bug 43126 by request.)
(Reporter)

Updated

18 years ago
Blocks: 43126
(Reporter)

Updated

18 years ago
Keywords: nsbeta2, regression
Component: XP Apps → Cookies
QA Contact: sairuh → tever

Comment 1

18 years ago
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [nsbeta2+]
(Reporter)

Comment 2

18 years ago
By removing <div>s and changing <fieldset> to <titledbox> as suggested by hyatt, 
the properties are now being displayed but not properly.  Here are the problems 
with the display:

- it takes a relatively long time for display to appear (it used to be 
intantaneoulsy as soon as you selected the cookie

- textfields of each property have "read only" attributes but they can be 
written into

- changing the selected cookie will cause the property textfields to flicker 
between white and grayed-out and the final color that they wind up in is almost 
random (I haven't figured out any pattern yet). 
Summary: Cookie properties are not being displayed in cookie viewer → Cookie properties are not being displayed properly in cookie viewer
Target Milestone: --- → M18

Comment 3

18 years ago
These are all textfield glitches.  The tree is now more or less ok.  You should 
probably file individual bugs against the owner of the textfield now.

Closing this one out.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 4

18 years ago
Who is the owner of the textfield?
(Reporter)

Comment 5

18 years ago
This bug is *not* fixed.  Will reassig to layout component.  If that's not the 
right owner, please tell me who it.
Status: RESOLVED → REOPENED
Component: Cookies → Layout
Resolution: FIXED → ---
(Reporter)

Comment 6

18 years ago
Reassigning
Assignee: hyatt → clayton
Status: REOPENED → NEW
QA Contact: tever → petersen

Comment 7

18 years ago
Triaging Clayton's list:
---------------------------

Eric, could you please take a look at this? I'm not sure who owns "textfield" 
bugs.
Assignee: clayton → pollmann

Comment 8

18 years ago
The bug with textfields is this:
 <input type=text readonly>

This is broken, but setting the readOnly attribute via the DOM works fine.  This 
is a new bug with Ender Lite.  Forwarding over to Mike.

In the old GfxTextControlFrame, the logic to do this is in:
nsGfxTextControlFrame::InitializeTextControl

Particularly, see the section after this line:
  // set readonly and disabled states

nsGfxTextControlFrame::InitializeTextControl was called by 
nsGfxTextControlFrame::InstallEditor.

The InstallEditor logic looks like it migrated into:
nsGfxTextControlFrame2::CreateAnonymousContent, so after the editor is 
initialized here, it should have it's readonly state set (and disabled and 
wrap too, probably.  ;)  )
Assignee: pollmann → mjudge
OS: Windows NT → All
Hardware: PC → All

Updated

18 years ago
Summary: Cookie properties are not being displayed properly in cookie viewer → readonly text fields are not readonly
(Reporter)

Comment 9

18 years ago
There are three symptoms grouped together in this report (see my comment of 
6-22) because I assumed they were all being caused by the same bug.  However, 
symptom #3 is not longer occuring (flickering between white and grayed out).  I 
suspect that perhaps Karnaze's changes for bug 43732 might have been responsible 
for fixing symptom #3.  However the first two symptoms still exist.

Comment 10

18 years ago
So in addition to the "readonly doesn't work" bug, there is also this:

- it takes a relatively long time for display to appear (it used to be 
intantaneoulsy as soon as you selected the cookie

Does this mean the text inside the text field is not updated immediately?  I've 
seen similar problems on other pages with many text inputs: 
http://blueviper/forms/test.html is a good example.  Notice how the text fields 
are all updated at different times and quite a bit after the page loads.  This 
used to happen faster before.
(Reporter)

Comment 11

18 years ago
Correct, the text inside the text fields are not updated instantaneously but 
rather take a noticible amount of time.  This may be related to bug 42471 -- 
that bug involves data that the user types into a text field whereas this one 
involves prefilled data in the text field.  But in both cases, there is a 
noticable delay as each character is entered.

Comment 12

18 years ago
setting to m17
Target Milestone: M18 → M17
(Assignee)

Comment 13

18 years ago
Assigning to kin@netscape.com, taking from mjudge per beppe.
Assignee: mjudge → kin
(Assignee)

Comment 14

18 years ago
Accepting bug.
Status: NEW → ASSIGNED
(Assignee)

Comment 15

18 years ago
Adding ETA of 07/14.
Whiteboard: [nsbeta2+] → [nsbeta2+] ETA 07/14

Comment 16

18 years ago
What things in the UI can be editted?  Is there a potential for an data loss in 
any of the UI fields?
Whiteboard: [nsbeta2+] ETA 07/14 → [nsbeta2+][NEED INFO] ETA 07/14
(Reporter)

Comment 17

18 years ago
The fields that can be modified are all the cookie properties -- it's name, 
value, host, expiration date, etc.  However the modifications mean nothing, you 
are not changing any of the cookie properties, you are only changing the display 
of the properties on the screen.  That is why they were given the read-only 
attribute in the xul.  But, unfortunately, that attribute is not being observed.

No, there's no potential for data loss, only for confusion if the user thinks he 
is really changing the cookie properties.

Comment 18

18 years ago
While there may be no potential for data loss in the Cookie UI, I should note
that *any* HTML or XUL text field that is intended to be readonly, is in fact
editable at this time. There is potential for data loss, particularly for an
HTML form that is relying on readonly state (admittedly that's uncommon).
(Assignee)

Comment 19

18 years ago
Fix checked in:

    mozilla/layout/html/forms/src/nsGfxTextControlFrame2.cpp  revision 1.55

Modified CreateAnonymousContent() and AttributeChanged() to set the editor's
readonly and disabled flags.
r=sfraser@netscape.com
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
Whiteboard: [nsbeta2+][NEED INFO] ETA 07/14 → [nsbeta2+]Fix checked in.
(Assignee)

Comment 20

18 years ago
Created attachment 11338 [details]
My ReadOnly/Disabled TextWidget test case.
(Reporter)

Comment 21

18 years ago
Pulled kin's changes and indeed it fixes the problem in the cookie viewer.  It 
is no longer possible to modify the contents of the cookie properties.  
Furthermore, I think the cookie properties are being updated quicker as well.  I 
don't recall just how "instantaneous" the update used to be before the 
regression started so I can't compare it, but it certainly seems acceptable now.

Thanks kin.

Comment 22

18 years ago
Fixed in the July 14th build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.