Closed Bug 14942 Opened 26 years ago Closed 26 years ago

Can't type anything in urlbar when full gfx switched on

Categories

(Core :: DOM: Editor, defect, P1)

Product:
Core
Component:
DOM: Editor
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: andreas.otte, Assigned: akkzilla)

References

Details

(Whiteboard: [HELP WANTED] can't reproduce)

If full gfx is switched on, the urlbar is gray with a white border and you can't type anything in it. I see this also in the ProfileManager when to type the ProfileName or ProfileDirectory.
Assignee: trudelle → buster
Component: XP Toolkit/Widgets → Editor
That is the Editor, which is not an XPToolkit widget, reassigning.
Assignee: buster → akkana
Severity: normal → blocker
Priority: P3 → P1
QA Contact: beppe → sujay
Summary: Can't type anything in urlbar when full gfx switched on → [blocker] Can't type anything in urlbar when full gfx switched on
Whiteboard: can't reproduce
Target Milestone: M10
akkana, sujay: is this a valid bug? are gfx text controls dead on linux? I can't reproduce this.
I don't see this problem on my own Linux build (a clean one from this morning or another one updated this afternoon plus some local changes). On what platform and build was this seen?
I have seen this for several days with the current tree on linux 2.2.10 / glibc 2.1 / GTK 1.2.0.
That's pretty close to my system's specs (though my kernel is only 2.2.5) and I just can't reproduce this. Exactly what do you do? Run apprunner, click in the urlbar, type and nothing happens? Or do you do something more elaborate to make this happen?
Severity: blocker → major
Status: NEW → ASSIGNED
Summary: [blocker] Can't type anything in urlbar when full gfx switched on → Can't type anything in urlbar when full gfx switched on
Target Milestone: M10 → M11
Andreas is away for a few days, so he suggested lowering the severity on this bug if no one else can reproduce it, and I've done so. Sujay, have you had any problems typing in the urlbar in the last few days?
I'm just starting apprunner. It comes up with this gray urlbar with a white border. If I switch to partial gfx all is okay. I will try to use a newer version of GTK and see if that fixes it.
GLIB/GTK+ 1.2.5 did not help, I'm still seeing this when full gfx is switched on.
It just occurred to me that you might be seeing bug 15195. Is it possible that the urlbar is getting your characters, and just not redrawing correctly? Try typing something in the urlbar, then hiding the apprunner window under another window then bringing it back to the front, to force a redraw. Do the characters you typed now appear?
No, no help here. I don't have a cursor in the field. I see the same problem in the profile manager, the addressbook and in the new-message dialog (subject). Must be the editor everytime.
Blocks: 15693
andreas -- can you reporduce this using a more current build? sujay -- can you reproduce this in-house?
Oh yes, it's still there whenever I switch to full gfx and start apprunner again. Although the size and shape of the gray area has changed, the white border is much smaller now ;).
It seems, I'm the only one with this problem. Any idea where in the Editor to look for the relevant source, so I can start to play with it?
andreas--we just changed key event handling on all platforms; you might start by looking at some of the files which were checked in today by ftang@netscape.com In particular, look at the files in widget/src/gtk.
It still happens with the landed KEY-EVENT-BRANCH. If think this is more related to painting the editor-field and maybe modality-issues.
latest win32 bin of browser doesnt allow anything to be typed after a ".", turns the rest into garbage and wont display the "."
Whiteboard: can't reproduce → [HELP WANTED] can't reproduce
Target Milestone: M11 → M14
Some places to start looking are: 1. In widget/src/gtk/nsGtkEventHandler.cpp, there are some debugging messages with #ifdef DEBUG_akkana there. Turn them on for you, and see if key events are being generated correctly. 2. Check for the editor event listener actually getting the event: in the main editor this is in editor/base/nsEditorEventListeners.cpp in nsTextEditorKeyListeners::KeyPress, but it might be in KeyPress in layout/html/forms/src/nsGfxTextControlFrame.cpp. Try setting breakpoints in both places, and if you get there, follow through to see if you get sent to InsertText in the editor.
You will not believe, what the reason was for this problem. I tested some weeks ago the jar-protocol-handler for judson valeski. Somehow the jar protocol kills the about-protocol, and about:blank was no longer working. This resulted in some strange behaviour, but nothing fatal ... this was one ... throwing out libnecko_jar.so cleared a lot of problems for me. Sorry for having bothered you with this ... this one is fixed for me ...
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
Yay! Thanks for the update.
Status: RESOLVED → VERIFIED
verified in 10/25 build.
You need to log in before you can comment on or make changes to this bug.