Closed Bug 66118 Opened 24 years ago Closed 23 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: 23 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: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME

    
    

    
  
err, fixed.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

    
    

    
  
Nothing to see here.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 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: