Closed
Bug 97663
Opened 23 years ago
Closed 22 years ago
editor toolbars/menus are disabled and no focus/caret if cache pref: Every time
Categories
(Core :: DOM: Editor, defect, P1)
Core
DOM: Editor
Tracking
()
VERIFIED
WORKSFORME
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!
Cc darin, I think he backed out some code last week that caused a similar problem.
Comment 3•23 years ago
|
||
when did this start happening?
Comment 4•23 years ago
|
||
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.
Comment 5•23 years ago
|
||
this seems to work fine now... tested with linux build 2001/10/01-08 ->WORKSFORME
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 6•23 years ago
|
||
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 → ---
Comment 7•23 years ago
|
||
*** Bug 102926 has been marked as a duplicate of this bug. ***
Comment 8•23 years ago
|
||
ok.. thanks for the details.
Updated•23 years ago
|
Keywords: helpwanted
Reporter | ||
Comment 9•23 years ago
|
||
*** Bug 105968 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
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
Comment 11•23 years ago
|
||
Marking nsbeta1+ per syd. Need to fix for composer usability.
Keywords: nsbeta1+
Comment 12•23 years ago
|
||
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.
Reporter | ||
Comment 13•23 years ago
|
||
*** Bug 111330 has been marked as a duplicate of this bug. ***
Comment 14•23 years ago
|
||
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
Comment 15•23 years ago
|
||
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 → ---
Reporter | ||
Comment 16•23 years ago
|
||
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
Comment 17•23 years ago
|
||
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.
Comment 18•23 years ago
|
||
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.
Comment 19•23 years ago
|
||
EDITORBASE triage: Need to discuss this with Darin
Comment 20•23 years ago
|
||
plussing, reassigning to darin
Assignee: syd → darin
Status: ASSIGNED → NEW
Whiteboard: [QAHP] EDITORBASE → [QAHP] EDITORBASE+
Comment 22•23 years ago
|
||
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.
Comment 23•23 years ago
|
||
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 :(
Comment 25•22 years ago
|
||
not much chance of me either!
Comment 26•22 years ago
|
||
Kin: any idea what we can do about this?
Assignee: cmanske → kin
Component: Networking: Cache → Editor: Core
Comment 27•22 years ago
|
||
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: 23 years ago → 22 years ago
Resolution: --- → WORKSFORME
Comment 28•22 years ago
|
||
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.
Description
•