Closed Bug 66118 Opened 25 years ago Closed 24 years ago

Problem closing Preferences after viewing Preferences -> History and then another category item

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: jlp.bugs, Assigned: bugzilla)

References

(Depends on 1 open bug)

Details

(Keywords: dataloss, regression)

Attachments

(1 file)

patch
2.98 KB, patch
Details | Diff | Splinter Review
I am using Mozilla 2001012020 on Windows 2000 SP1. Steps to reproduce: 1. Open Preferences (Edit -> Preferences...) 2. Go to Navigator -> History category 3. Go to other category 4. Try clicking OK button to exit Preferences Expected result: Preferences closed and data saved. Actual result: Nothing happens when you click OK. Reproducable: Always I also found out that changing preferences in other categories doesn't help. The only thing you can do is click Cancel or close the windows with X button in the titlebar. The OK button closes Preferences window if you have Navigator -> Histoy selected in any situation, as expected. But if you have any other category selected OK button does nothing.
BTW: With "other category" I mean any top or sub category in Preferences. Except Navigator -> History subcategory.
Summary: Problem closing Preferences after visiting Preferences -> History and then another category item → Problem closing Preferences after viewing Preferences -> History and then another category item
Adding 40891 to the blocks: list.
Blocks: 40891
Radha, your recent patch caused this. We can't just do document.getElementById ('shistMax') in the OK callback function because each pref pane is a different document, so if you press OK in preferences when you're in a pane other than History, shistMax won't exist in the document. I'll try to get a patch together for the right way to do it...
Assignee: matt → radha
Status: UNCONFIRMED → NEW
Component: Preferences → History
Ever confirmed: true
Keywords: regression
OS: Windows 2000 → All
QA Contact: sairuh → claudius
Hardware: PC → All
Hmm...I was creating a patch for this and then realized that we only need this callback to ensure that we don't save a pref < 0. If that is, indeed, the only reason for it, I think this is better fixed in the UI itself. In this case, it seems like we could solve this by only allowing numbers to be typed into the textfield, no?
Taking, marking dependency on 66163
Assignee: radha → blakeross
Depends on: 66163
*** Bug 67641 has been marked as a duplicate of this bug. ***
*** Bug 69109 has been marked as a duplicate of this bug. ***
I reported bug <A HREF="http://bugzilla.mozilla.org/show_bug.cgi?id=67641">67641</A> which was marked as a dupe of this one. I can verify this is the actual problem. Before I said that "clicking around multiple panels" caused the problem but it is indeed clicking the History one that causes the OK button to die. Further info, if you go to History, go around and set some more preferences, then go *back* to History, you can click OK, saving the changes you made. This is with Build ID 2001021508 on Mac OS 9.1.
*** Bug 69503 has been marked as a duplicate of this bug. ***
*** Bug 69574 has been marked as a duplicate of this bug. ***
*** Bug 69643 has been marked as a duplicate of this bug. ***
*** Bug 69645 has been marked as a duplicate of this bug. ***
*** Bug 70144 has been marked as a duplicate of this bug. ***
*** Bug 70144 has been marked as a duplicate of this bug. ***
no improvement yet in 2001022800 for OS/2
Put an input handler on the textfield and be done with it?
*** Bug 70516 has been marked as a duplicate of this bug. ***
*** Bug 70593 has been marked as a duplicate of this bug. ***
This bug has 9 duplicates. It should be made mostfreq.
I can still verify all this on 2001031604. Ross knows exactly what line of code produces this bug.
*** Bug 73536 has been marked as a duplicate of this bug. ***
Mostfreq, major, dataloss, nominating for 0.9 (this bug has _9_ votes). I'm amazed that a simple thing like this that has a nasty (and confusing) impact on anyone trying a mozilla build hasn't been addressed. Why wasn't this fixed for 0.8.1?? I pulled down a Win32 0.8.1 build last night and got caught by this, and lost a lot of preference editing. Also, why does this depend on bug 66163??? Here's the initial comment from that bug: Clients should be able to specify generic masks for textfields, like only allowing letters, numbers, or alphanumeric characters. Just assigning this to me for the work...
Severity: normal → major
Keywords: dataloss, mostfreq, mozilla0.9
I'm rather surprised there hasn't been more traction on this as well. Keep in mind that the workaround to prevent the dataloss (that no random user will figure out) is to return to the history panel to press 'OK'. adding nsbeta1 keyword.
Keywords: nsbeta1
Attached patch patch — — Splinter Review
cc'ing alec for sr
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
Lets get this in.
ouch. sr=alecf one of these days I'm going to give session history a beating.
*** Bug 74671 has been marked as a duplicate of this bug. ***
Fixed with landing.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 75251 has been marked as a duplicate of this bug. ***
*** Bug 74846 has been marked as a duplicate of this bug. ***
Is this fixed in 0.9.1? If the patch made it in, then we have a problem, because I'm still getting the same error.
Prefs OK button still not working from Advanced/system with 0.9.1 on NT4 (Cancel works).
2001060817 OS/2 Prefs OK button broken (Cancel works). Is this related to applying modern?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
We already have a bug on that. Is anyone still seeing the history problem reported here? I'm not.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
err, fixed.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Nothing to see here.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
move along. VERIFIED Fixed with 2001061406 builds
Status: RESOLVED → VERIFIED
Broken again in 2001120411 OS/2.
Fixed in 2001121219
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: