Closed Bug 71224 Opened 24 years ago Closed 24 years ago

toolbar buttons appear grayed out when new composer window is launched

Categories

(Core :: DOM: Editor, defect)

x86
Linux
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: shrir, Assigned: blizzard)

References

Details

(Keywords: regression, smoketest, Whiteboard: [QAHP])

Linux only, could not find a duplicate bug.. Steps: Launch browser Click on Tasks->Composer Observe that a new blank composer window launches. The formatting toolbar, Composition toolbar buttons appear grayed out initially. If you click once, the formatting toolbar buttons appear enabled and if you type something then the composition toolbar buttons appear enabled. Expected: toolbar buttons should appear enabled when a new window is launched.
does it matter what skin you use? This sounds like a focus problem; cc some others who may know of a dup
kathy: classic, blue, modern..all skins show this
Shrir -- is the caret visible in the Composer window when the window first opens?
beppe: No, the caret is not visible initially
then the editor window is not getting focus when it is first opened. saari -- can you take a look at this?
Assignee: beppe → saari
Is it not getting focus, or do we have JS errors on launch?
this is a duplicate of #53630 *** This bug has been marked as a duplicate of 53630 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
this is the correct bug...reopening
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 53630 has been marked as a duplicate of this bug. ***
severity major..I can workaround this problem..by typing some text and enabling menus and buttons..
Severity: normal → major
typing some text does not enable buttons for me. This also breaks message compose for me on linux build 031305. I can't send mail!!! the menu buttons are all grayed out, even after typing a message! This is a blocker.
Severity: major → blocker
Keywords: nsdogfood, smoketest
This bug is not assigned to the right person. It doesn't appear to be a focus problem since I can type in the window. I don't see anything obvious in the console. This bug is XP. Apparently mail compose is also broken.
Assignee: saari → cmanske
Status: REOPENED → NEW
OS: Linux → All
Hardware: PC → All
Just great. As brade said, this is not assigned to the right person! I don't see any problem in my current debug build (current as of 3/12, WinNT4). I'm pulling and rebuilding now and will investigate ASAP.
could this be the result of mcafee's checkins to 68074 (I'm just guessing here and probably wrong)
brade and akkana: Do either of you see this problem? Any useful messages in the debug window? Any assertions on editor startup? P.S., please use "bug", e.g., "bug 68074" for bug numbers so they get turned into links (I think this may be new bugzilla behavior.)
Yes, I see this on my Mac build. I'm having problems pulling on Windows. I don't see any new assertions nor anything useful in the console (though something useful *may* be buried in there).
or possible pinkerton's checkin for bug 71722?
why would my changing mac-only menu IID's have any impact on composer buttons? and i did that yesterday, this bug has been around for a week now.
I don't really think pink's checkin is the problem either, but this bug (and related problems) are new in todays build. There's been intermittent reports like this before, but I think today it has really reared its ugly head!
I didn't see the previous problems, but I'm definitely seeing today's problem on Linux. All the toolbar buttons are grey, and clicking/typing in the window doesn't activate them.
*** Bug 71821 has been marked as a duplicate of this bug. ***
I was testing menus for bug 45108 last night with yesterday's build and these problems weren't there. Also note that the context menu is empty. Probably related. Is there some sort of initialization routine that isn't getting fired?
Using the 031208 linux build, I don't see this problem. Using the 031221 linux build, the toolbars are initially greyed out but if I type, they enable. They still don't work, though. Using the 031308 linux build, toolbars stay greyed out even if I type.
joki, this looks like you. Please be on the hook to assist.
Reassign to joki; this is from his checkin. He is working on a fix.
Assignee: cmanske → joki
Fixed.
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
With joki's checkin, this is much better: if I bring up an editor from the browser window, I see the toolbar buttons and they work. However, if I run mozilla -editor, it still comes up with the toolbar buttons greyed out. If I type, the buttons enable, and they work correctly, so this is definitely much better than it was, but if I wanted to make a page that contained, say, a table and nothing else, I might not be able to do it. I'll let others test and decide whether the bug should be reopened for this.
Akkana, is there a separate bug filed for thhe mozilla -editor part ?
Sujay: No, but it turned out that mozilla -editor wasn't really any different from bringing up the editor from a browser window.
This is still not fixed. Just tried it latest Linux build. works on Mac and Win...changing platform/OS.
OS: All → Linux
Hardware: All → Other
reopening per sujay's comments
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
workaround of typing enabling the toolbar makes this not a blocker, lowering severity to critical to get off smoketest blocker radar.
Severity: blocker → critical
Since we're back to a state where the workaround works, converting this to catfood. Removed smoketest keyword since Granrose declared this not a smoketest blocker. Anyone have a new theory on why the buttons still don't enable at window creation time?
Whiteboard: [QAHP]
*** Bug 72927 has been marked as a duplicate of this bug. ***
*** Bug 74285 has been marked as a duplicate of this bug. ***
Assignee: joki → beppe
Status: REOPENED → NEW
Hardware: Other → PC
Target Milestone: --- → mozilla0.9
I'm not sure Joki is working on this bug; reassign to beppe to get Composer team's attention.
We all know about the problems. How is reassigning to beppe supposed to help? It isn't an editor problem, but an events/command updater problem.
This bug should be dependent on the bug about the throbber not stopping when loading pages in the browser.
Depends, at least in part, to the throbber not stopping bug.
Depends on: 39310
cmanske: editor is using some ? event/updater code in a way that none of the other windows do, so in that sense it IS an editor problem. 39310 is a meta bug, we should find the real bug this depends on. Typing to gain back menu items isn't very discoverable, we should look for a simple workaround if event/updater problem isn't gonna get fixed.
Oh, we're going to have to fix the event/updater problem, wherever it lies.
so, who should really own this bug then -- is it really an event/updater issue? If so, then this needs to go to the correct owner -- which is who?
Moving to mozilla0.9.1.
Target Milestone: mozilla0.9 → mozilla0.9.1
Taking off of beppe's plate since she can't debug this.
Assignee: beppe → kin
Blocks: 63378
this has regressed to remaining greyed out all the time...back to smoketest blocker
Severity: critical → blocker
cc:ing dr, since he made focus-related changes and this bug seems to have been related to focus problems in the past
With my Linux build from this morning, I see that no caret shows up on Linux until I click in the content area of Composer. Once I click and then type, all of the toolbar items enable.
yeah...working fonr for me excepr for the origonal problem mentioned here (buttons apprea grayed out initially when I load a blank page). But when I type , the buttons do get enabled and things work. used today's commercial build on linux 0425.
Okay, this isn't a blocker. Typing in the new composer window first thing brings up the tool bar as before reducing back to critical To reproduce what I was seeing, follow these steps: -open composer window -select Debug | Insert Text after doing that, the tool bar doesn't become active even if typing in new text
spam: really reducing
Severity: blocker → critical
Some debugging shows what I suspected; focus is not behaving the same way on linux than other platforms. The editor JS is doing: window._content.focus(); window.updateCommands("create"); where window.updateCommands() results in calls to var controller = top.document.commandDispatcher.getControllerForCommand(command); if ( controller ) enabled = controller.isCommandEnabled(command); On linux, 'getControllerForCommand' fails here, whereas it works on other platforms. Is focus() asynchronous on linux, or something like that?
Wow, we're talking about focus and no one cc'ed me? Silly people. :) When you call window._content.focus(); does the toplevel window actually have focus?
Stealing this linux focus bug.
Assignee: kin → blizzard
*** Bug 77532 has been marked as a duplicate of this bug. ***
any status on this bug? would be nice to fix...
Will be fixed with the checkin from 76617.
Depends on: 76617
Fixed with the checkin from 76617.
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Shrir: please check if this has also fixed bug 75568.
twalker, see if this happens with 5/4 builds...
*** Bug 75568 has been marked as a duplicate of this bug. ***
verified on linux commercial build 2001-05-04-08-trunk
Status: RESOLVED → VERIFIED
in 5/14 build I see this problem again.. REOPENING.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
hmm..works fine for me on 0515 trunk on linux.
sujay, this can be reproduced if one uses debug image insert to insert text into the composer window...otherwise it's working fine
okay it works now....
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
verified in 5/15 build.
Status: RESOLVED → VERIFIED
This is broken again in Composer, far as i can tell. Buttons are disabled, menuitems likewise. Clicking in page does NOT help - have to actually write something there to open a file, and then i'm first prompted to save what i wrote - even if it's deleted again.
You need to log in before you can comment on or make changes to this bug.