Closed Bug 70742 Opened 24 years ago Closed 23 years ago

unable to focus, or enter text in some pref panel textfields if another pref panel is viewed first

Categories

(SeaMonkey :: Preferences, defect, P2)

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.2

People

(Reporter: ratman, Assigned: eddyk)

References

Details

(Keywords: helpwanted, regression)

Attachments

(4 files)

using win32 installer mtrunk build 2001030205 (the respin?). un) open edit -> preferences deux) select any preference panel other than the main navigator pref panel trois) select the main navigator pref panel quatre) click and/or start typing in the textarea in order to type in a url expected behavior) textarea receives focus and/or words start appearing actual behavior) rien [nada] since the main navigator pref panel is the default one upon entering the preferences, if you don't switch to a different pref item, the home page textarea works just fine. the bug occurs only if you first visit another panel and return. perfectly repeatable. this is a new-for-today bug, i didn't see this with yesterday's win32 mtrunk installer build.
OS: other → Windows 98
Summary: cannot focus and/or enter a home page if another pref panel viewed first → cannot focus and/or type in a home page if another pref panel is viewed first
maybe it has gone away again?
ben or blake, would this belong to you? reassign as needed, thx! i see this on mac and linux, too. nominating for beta1...also tempted to nominate for moz0.8.1 [i know, it's last moment, but this is a rather annoying regression].
Assignee: matt → ben
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsbeta1, regression
OS: Windows 98 → All
Hardware: PC → All
*** Bug 70887 has been marked as a duplicate of this bug. ***
also unable to bring up the context menu for this textfield [from bug 70887].
affects other textfields in prefs, eg Cache: 1. open prefs dialog. 2. go to Cache panel, notice that you can bring into focus and type in the textfields. 3. go to another panel, eg, Appearance. 4. return to Cache panel and attempt to edit textfields. result: unable to focus or edit textfields. i went over this w/jrgm, who also sees the behavior, but oddly enough we found that it wasn't reproducible in the Proxies panel. hrm. hyatt/saari, would this belong to you?
Severity: normal → major
Summary: cannot focus and/or type in a home page if another pref panel is viewed first → cannot focus, type or bring up context menu in a textfield if another pref panel is viewed first
Also seeing this, Windows 2000, Mozilla 2001031120 installer. Classic and Modern theme Maybe helpful: - When going to Composer / 'New Page Settings', choose another pref-panel, and og back to the 'New Page Settings' page, the 'Author' text field stopped working, but the 'Background image' text field is still working. - On a non-functional edit field, the mouse does not change to an I-beam when over the text field, but does change to an I-beam when over the text-field border. - The text field is also removed as a tab-stop, when tabbing through the fields with the keyboard it doesn't go to the non-functional textfield.
Marking nsbeta1+, p2, mozilla0.9
Keywords: nsbeta1nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla0.9
CC'ing bryner since some view manager changes that are related to focus may be involved here
*** Bug 73977 has been marked as a duplicate of this bug. ***
up a level. not mine.
Assignee: ben → vishy
passin' over to mcafee, to see if he can fix it --or know the right person who could. thx!
Assignee: vishy → mcafee
->aaronl, could you take this? also nominating for moz0.9.1 --since i doubt a fix for this will make it to 0.9. unless i'm wrong (which i wouldn't mind here ;) and someone here *does* have a fix that'd cover this...
Assignee: mcafee → aaronl
Keywords: mozilla0.9.1
Blocks: 75643
using win32 installer mtrunk build 20010411?? no fix here, but an interesting observation: after displaying a panel, moving on, and then returning, the cursor over the textfield is a standard one, instead of an i-bar. the exception, however, is the left and right edges of the textfield box, where not only does an i-bar cursor appear, but so does a context menu, although there really isn't anything to copy/cut/paste from a null selection (though selecting all and copying will overwrite previous clipboard contents). i really doubt it, but could this be a borders issue?
One problem per bug report, please! Open new bug reports for other problems. This report is about an inability to type in the URL text field following steps un...quatre. I can reproduce this in today's NS installed bits on Win98, but not in mozilla builds from today. Reassigning to component owner to ensure that installer is getting everything right. clearing target for re-triage.
Assignee: aaronl → mcafee
Target Milestone: mozilla0.9 → ---
- actually, this bug expanded to the failure to focus, to bring up a context menu, and to enter text into *several* preference panel textfields - please see sairuh's previous comment regarding the cache panel and discussion with jrgm. summary is reworded to reflect this. - my apologies for essentially dittoing ajbanck's previous comment with my last one. - there may be a relation here with previous issues over the history pref panel textfield - i'll dig up bug numbers soon.
Summary: cannot focus, type or bring up context menu in a textfield if another pref panel is viewed first → unable to focus, bring up context menu, or enter text in some pref panel textfields if another pref panel is viewed first
*** Bug 76957 has been marked as a duplicate of this bug. ***
Keywords: helpwanted
The textfields keep working if you remove the 'parent.initPanel()' stuff out of onload="" It seems that something in onpageload in nsPrefWindows.js, is the cause or triggers this bug because I don't have this problem after taking it out!
*** Bug 79396 has been marked as a duplicate of this bug. ***
Timeless, eddyk, might this be due to your checkin on march 1st to enable prefIsLocked stuff? Commenting out the patch doesn't fix the bug but maybe you guys have an idea about this.
it shouldn't. But i don't know enough to be sure (nor am i awake enough to right a clear/accurate/polite comment). If you think it's my bug, reassign to me, otherwise I have other stuff to do. Considering Ben didn't want the bug I'm going to assume i don't want it either.
Arg. I removed my changes on onpageload, but bug is still there. I change the WSM attribute initialiser for disabled properties, and the bug seems to disappear. this.wsm.attributes = ["pref", "preftype", "prefstring", "prefattribute", "disabled"]; to this.wsm.attributes = ["pref", "preftype", "prefstring", "prefattribute"]; arg. Another thing I just noticed while playing around with this is that context menus come up only once. The second right click in a textfield doesn't do anything. arg
Is that 'disabled' used for something like .setAttribute("disabled","fale") on a <textbox> ? note: contextmenu bug is bug 78725
Ok found the problem is generic_Set: in nsWidgetStateManager.js generic_Set: function ( aElement, aDataObject ) { if( aElement ) { for( var property in aDataObject ) { aElement.setAttribute( property, aDataObject[property] ); // this is HJ's small hack, check for element textbox if ( aElement.nodeName == "textbox" && property == "disabled" ) { // Yes sir, textbox it is if( aDataObject[property] == "false" || DataObject[property] == "" ) { // We don't need crap, so remove this attribute aElement.removeAttribute(property); } } } } }, Sorry no diff but this will do the trick.
It seems to work, BTW the code you posted has a typo. However, I have a question. Should the textbox be fixed? It was in a semi-disabled state when the disabled property was set to a non-null, non-true value. Either it should be disabled or be enabled, IMO. Should another bug be filled to fix textfields instead of working around it in WSM? Thanks!
How about this diff instead (if this approach is the right one to take)? This would also take care of bug 76937. Basically don't set disabled if it's an empty string or false for any xul element. Index: mozilla/xpfe/global/resources/content/nsWidgetStateManager.js =================================================================== RCS file: /cvsroot/mozilla/xpfe/global/resources/content/nsWidgetStateManager.js,v retrieving revision 1.16 diff -u -r1.16 nsWidgetStateManager.js --- nsWidgetStateManager.js 2001/05/09 08:32:51 1.16 +++ nsWidgetStateManager.js 2001/05/09 23:51:46 @@ -192,6 +192,11 @@ for( var property in aDataObject ) { aElement.setAttribute( property, aDataObject[property] ); + if ( property == "disabled") { + if (aDataObject[property]=="false" || aDataObject[property]=="") { + aElement.removeAttribute(property); + } + } } } },
Hey, we at least now know what the problem is :) I have filed a bug for textboxes, bug 72157, but that one is marked 'Future' so that won't help us. Hyatt told me on IRC that the widgets are going to be changed in the near future. We could close this bug, and bug 76937, with this workaround. Or we could also fix bug 72157 by doing this in xulBindings.xml#383.
oops, make that xulBindings.xml#247 for <textbox>
Who can update the summary because the context menu bug is reported in bug 78725. Let focus on the focus/enter text thing here. The reason for this is that some people on IRC told me that this bug is invalid because there are to may different issues reported in this bug!
eddyk
Assignee: mcafee → eddyk
Summary: unable to focus, bring up context menu, or enter text in some pref panel textfields if another pref panel is viewed first → unable to focus, or enter text in some pref panel textfields if another pref panel is viewed first
have asked blake for r= and ben for sr=
if ( property == "disabled") Remove that extra space, please. Looks okay otherwise, I guess. r=blake
I'm a style nazi... + if ( property == "disabled") { + if (aDataObject[property]=="false" || aDataObject[property]=="") { try: aDataObject[property] == "false" || aDataObject[property] == "" (with spaces) Do you mean only empty string? Because if you also mean null or undefined, ! aDataObject[property] is more generic. But if you explicitly mean empty string what you have is fine. Otherwise, sr=ben.
After explaining to someone else how the fix worked, I realised that the check was being done unnecessarily inside a loop. So I move the check/removeAttribute from inside the for loop, to after the loop. Performance shouldn't be hit as badly now.
Fix checked in, marking fixed. Great job H-H!
It's late, I meant H-J of course.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Attached patch original logic, new place. (deleted) — Splinter Review
Going back to original check as done by H-J. Using the simplified form seems to be too generic, causing the disabled property to be removed overzealously. This breaks preflocking. So this final attempt is a combination of the original logic, but moved outside of the loop.
reopening so that I can get sr again.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: --- → mozilla0.9.1
Setting target milestone to 0.9.2 (check it in anytime, even before, when the tree is open for). Per PDT triage.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
marking fixed
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
cool! vrfy fixed using opt comm bits: winnt - 2001.05.17.10 linux and mac - 2001.05.17.08
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: