Closed Bug 97663 Opened 24 years ago Closed 23 years ago

editor toolbars/menus are disabled and no focus/caret if cache pref: Every time

Categories

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

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
mozilla1.0

People

(Reporter: Brade, Assigned: kinmoz)

References

Details

(Keywords: helpwanted, Whiteboard: [QAHP] EDITORBASE+ [adt2])

If the cache preference is set to "Every time I view the page", when I create a new composer document, the caret is missing and all of the icons are disabled on the toolbar. The editor appears completely broken (can't quit/change prefs/etc.) Note: I commented on the different behaviors of this preference in bug #97626 We need to investigate and get this fixed soon!
We probably miss the load notifications.
Assignee: gordon → darin
Cc darin, I think he backed out some code last week that caused a similar problem.
when did this start happening?
Charley said he saw it possibly as early as Thursday 8/23. I wasn't able to try Thu/Fri builds due to installer crashes and working from home on an old tree, but I saw it on Monday's build.
this seems to work fine now... tested with linux build 2001/10/01-08 ->WORKSFORME
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Reopening bug; I still see this with my Mac debug build from the trunk today. Be sure to set your cache preference to "Every time I view the page" Then create a new composer page and type "abc" (note: do *NOT* click in the window/editing area). Results: no characters are shown in the editing area and the toolbar along the top is disabled except for "New" Note: if you do click in the editing area, the caret will be placed and you can type but the toolbar isn't enabled. I do not see this bug if I change my Cache preference to another option.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
*** Bug 102926 has been marked as a duplicate of this bug. ***
ok.. thanks for the details.
Keywords: helpwanted
*** Bug 105968 has been marked as a duplicate of this bug. ***
Summary: editor toolbars/menus are disabled and no caret if cache pref: Every time → editor toolbars/menus are disabled and no focus/caret if cache pref: Every time
Whiteboard: [QAHP] EDITORBASE
-> 0.9.8
Priority: -- → P1
Target Milestone: --- → mozilla0.9.8
Marking nsbeta1+ per syd. Need to fix for composer usability.
Keywords: nsbeta1+
During last weeks prefs horkage my cache sizes (disk/mem) were set to 0 without my assistance. That caused me to see this bug, even if my pref for cache was set to compare "Automatically". I had to write something in a blank page before the menuitems and icons enabled. So: Cache size 0 is also a culprit.
*** Bug 111330 has been marked as a duplicate of this bug. ***
seems to me that imagelib depends on the cache, and without it stuff starts breaking. -> pavlov
Assignee: darin → pavlov
Status: REOPENED → NEW
Component: Networking: Cache → ImageLib
QA Contact: tever → tpreston
Imagelib doesn't care if the cache exists at all. It will happily just go and redecode. This sounds more like a focus or XUL document loading problem (or maybe XUL cache?)
Assignee: pavlov → joki
Component: ImageLib → Event Handling
QA Contact: tpreston → madhur
Target Milestone: mozilla0.9.8 → ---
This is not a focus or event problem. This problem only happens when the cache preference is set to particular settings. Reassign to Syd for better reassignment.
Assignee: joki → syd
Component: Event Handling → Networking: Cache
pavlov: i thought that some image loads depend on the image cache. i recall some sort of pattern for certain chrome images in which an image load would only succeed if it came from the cache. i'm not sure this is by design, but i think it would explain this problem. iirc: i noticed this when rewriting the resource protocol. i had a bug that caused problems for res/arrow.gif, but not other chrome elements. there is something different in the way res/arrow.gif is loaded.
Is this really a nsbeta1+, P2? If yes, then we need to try and targeted to a mielstone M1.0 or earlier to make the beta.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
EDITORBASE triage: Need to discuss this with Darin
plussing, reassigning to darin
Assignee: syd → darin
Status: ASSIGNED → NEW
Whiteboard: [QAHP] EDITORBASE → [QAHP] EDITORBASE+
-> syd (why did you reassign this to me?)
Assignee: darin → syd
Darin: the reason you got the bug is that it happens because this combination of cache prefs result in editor not getting the onload notifications it needs to initialize itself.
i don't know the first thing about how or when onload handlers fire... are you sure there isn't someone more knowledgeable about such things who could take this one? i'm open to learning more about onload handlers... but i'm pretty busy right now with other things :(
Whiteboard: [QAHP] EDITORBASE+ → [QAHP] EDITORBASE+ [adt2]
no chance of me doing this
Assignee: syd → cmanske
not much chance of me either!
Kin: any idea what we can do about this?
Assignee: cmanske → kin
Component: Networking: Cache → Editor: Core
I just tested this again and I don't see the problem. I believe it was fixed by the fix for bug 128134, which bypasses the cache when we load any URL into a Composer window.
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → WORKSFORME
I am also NOT seeing this problem on the 05-09 trunk build. Marking VERIFIED. If anyone is still able to reproduce the problem, feel free to reopen this bug.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.