Closed Bug 399242 Opened 17 years ago Closed 16 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)

x86
Linux
defect

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.
Keywords: regression
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
Component: Composer → XPCOM
Depends on: 380813
Product: Mozilla Application Suite → Core
Status: UNCONFIRMED → NEW
Ever confirmed: true
Thanks, timeless. Neil, can you take this?

/be
Flags: blocking1.9+
Assignee: composer → nobody
QA Contact: xpcom
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
Blocks: 380813
No longer depends on: 380813
Enn, can you back the appropriate files out for me?
Assignee: nobody → enndeakin
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Bug 399242 was backed out to fix more egregious bustage.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This should be fixed again
Status: REOPENED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.