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.)
Component: XP Apps → Cookies
QA Contact: sairuh → tever
Putting on [nsbeta2+] radar for beta2 fix.
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
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
Who is the owner of the textfield?
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 → ---
Assignee: hyatt → clayton
Status: REOPENED → NEW
QA Contact: tever → petersen
Triaging Clayton's list: --------------------------- Eric, could you please take a look at this? I'm not sure who owns "textfield" bugs.
Assignee: clayton → pollmann
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
Summary: Cookie properties are not being displayed properly in cookie viewer → readonly text fields are not readonly
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.
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.
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.
setting to m17
Target Milestone: M18 → M17
Assigning to firstname.lastname@example.org, taking from mjudge per beppe.
Assignee: mjudge → kin
Status: NEW → ASSIGNED
Adding ETA of 07/14.
Whiteboard: [nsbeta2+] → [nsbeta2+] ETA 07/14
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
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.
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).
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. email@example.com
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
Whiteboard: [nsbeta2+][NEED INFO] ETA 07/14 → [nsbeta2+]Fix checked in.
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.
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.