Closed
Bug 399242
Opened 17 years ago
Closed 17 years ago
When a read-only file is open, many menu items do nothing (fail silently, no write access, permissions, bits)
Categories
(Core :: XPCOM, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla1.9beta3
People
(Reporter: Aleksej, Assigned: enndeakin)
References
Details
(Keywords: regression)
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a9pre) Gecko/2007100902 SeaMonkey/2.0a1pre
WFM with Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.8pre) Gecko/20071008 SeaMonkey/1.1.5pre
Create two files, one read-write, and one read-only. For example:
touch 1.html
touch 2.html
chmod a+r-w 1.html
chmod a+rw 2.html
Open them in SeaMonkey Composer.
Try using various menu items - for example, Format → Page Title and Properties.
Actual results:
With the read-only file, nothing happens, and nothing appears in the Error console (note that you cannot open Error console from that window using menu, either).
Format: Discontinue Text Styles and Discontinue Link text is invisible, except for the hotkeys.
Some items, like edit modes in View and Spellcheck as you type, seem to switch modes, but I am not sure if they actually do anything else.
With the read-write file, menu items work properly.
Expected results:
Available features work properly, unavailable ones are disabled correctly.
Reporter | ||
Updated•17 years ago
|
Keywords: regression
Reporter | ||
Comment 1•17 years ago
|
||
Regression range is between the nightly 2007072501 and 2007072603: http://tinyurl.com/25g8v3
Probably bug 380813.
offhand, the patch in bug 380813 seems scary broken.
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/xpcom/io/nsLocalFileWin.cpp&rev=1.176&mark=752,757#747
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/xpcom/glue/nsIClassInfoImpl.h&rev=3.3&mark=52,53-55,141,146,148,166,172,174#50
I'm fairly certain nsIClassInfo should *not* be one of the args to NS_IMPL_ISUPPORTSx_CI
Updated•17 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•17 years ago
|
Assignee: composer → nobody
QA Contact: xpcom
Assignee | ||
Comment 4•17 years ago
|
||
I think maybe we should just back out bug 380813 and try again for a later release, I think the code and feature needs a bit of work overall.
let's back it out. in reading the other bug it seems that there is a second bug that also feels that bug isn't ready.
note: i shouldn't be the one to do the backout. and i shouldn't be asked to write any patches.
Priority: -- → P1
Target Milestone: --- → mozilla1.9beta3
Updated•17 years ago
|
Comment 6•17 years ago
|
||
Enn, can you back the appropriate files out for me?
Assignee: nobody → enndeakin
Assignee | ||
Updated•17 years ago
|
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Comment 7•17 years ago
|
||
Bug 399242 was backed out to fix more egregious bustage.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 8•17 years ago
|
||
This should be fixed again
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•