Closed
Bug 71096
Opened 24 years ago
Closed 24 years ago
Can no longer select acct level on New Folder, Search dropdowns.
Categories
(SeaMonkey :: MailNews: Message Display, defect, P1)
SeaMonkey
MailNews: Message Display
Tracking
(Not tracked)
mozilla0.8.1
People
(Reporter: laurel, Assigned: racham)
References
Details
(Whiteboard: [nsbeta1+] reviewed and tested (relnote 0.8.1))
Attachments
(1 file)
Using mar6 commercial trunk build
Something happened recently and you can no longer select the account level when
using acct/folder hierarchy dropdowns such as with New Folder or Search
Messages. The "choose this folder" line is no longer displayed, however if you
do select the (nonexistent) selection it will work.
1. From mail window, Search|Search MailNews Messages.
2. Try to select another account at the account level, i.e. account level for
Local Folders.
Result: "choose this folder" or substitute for it is missing.
Expected: an easily identifiable selection for account level to be offered and
selectable.
Note: seen with New Folder and Search Messages dialogs. Does not apply to
Move/File/Copy messages. Can't think off-hand if there'd be another applicable
dialog.
Doh. Of course it would apply when moving messages to a folder with subfolders,
to choose the parent folder.
*** Bug 71104 has been marked as a duplicate of this bug. ***
Comment 3•24 years ago
|
||
I see this too. It makes it so it's very hard to move/copy messages. marking
nsbeta1+ and moving to mozilla0.8.1. Reassigning to racham. cc'ing naving. Can
one of you guys look into why all of our folder menus are messed up?
Assignee: sspitzer → racham
Priority: -- → P1
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.8.1
*** Bug 71311 has been marked as a duplicate of this bug. ***
This is a regression (most probably indirect) introduced sometime between 3/5
and 3/6. Mailnews seems to be the only app affected by this. Looking at all
possible cases. Working ont it. Will update status as I find things.
Status: NEW → ASSIGNED
Tried backing out couple of suspicious changes. But still didn't option in the
menupopup to select the main folder. Will look at couple of more things. We need
hyatt's help here. Adding him to the cc list.
Updated•24 years ago
|
Whiteboard: [nsbeta1+] → [nsbeta1+] need status update
We have a solution now. Thanks to hyatt & hewitt.
Today, we have menuitem resources under the template builder as uri="..." and
that caused it to always have a menupopup child. It has been like that all
along. Then on 5th, hyatt made xbl rules more strict and did not allow any
children under menuitem. So, that caused this regression. So, all references to
resources (uri="...") for menuitems in these cases have to be removed.
I will post a patch with these changes covering all broken mailnews cases. As
there is a big merging effort going on with tip (perf branch with tip) rightnow,
it will be better to land this patch on the 0.8.1 branch when it is cut.
patch coming up...
Whiteboard: [nsbeta1+] need status update → [nsbeta1+] patch coming up...
Comment 10•24 years ago
|
||
racham, this bug is exactly the same as your File Here bug. You have an
incorrect uri="..." on static objects inside the template that causes the
template builder to place a <menupopup> underneath a <menuitem>. Now that the
<menuitem> binding has been properly tightened up to disallow this, the
anonymous content is not going to be built.
JUst patch your code to remove the uri="..." so the template builder will not
build a <menupopup> underneath a <menuitem>.
Assignee | ||
Comment 11•24 years ago
|
||
testing all cases now..
Whiteboard: [nsbeta1+] patch coming up... → [nsbeta1+] testing the patch
Assignee | ||
Comment 12•24 years ago
|
||
Discovered some problems with Move and Copy routines which take event.target as
input param. Removing the resource reference (uri="...") made event.target
useless as there will be no resource id to be associated with the selection we
make on the menus presented.
Spoke to hyatt about this. The current template structure allows us to depend on
the grandparent (a menu) here to pass the right target (i.e.,
event.target.parentNode.parentNode) to the MsgMoveMessage and MsgCopyMessage
functions to obtain the correct RDF resource. So, I am changing all instances
that need to be changed accordingly.
Changing the Summary to 'working on patch'.
I will list out all test cases, once I am done with this patch.
Whiteboard: [nsbeta1+] testing the patch → [nsbeta1+] working on patch
Comment 13•24 years ago
|
||
*** Bug 72568 has been marked as a duplicate of this bug. ***
Comment 14•24 years ago
|
||
*** Bug 72594 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 15•24 years ago
|
||
Assignee | ||
Comment 16•24 years ago
|
||
Gayatri, Seth and Hyatt,
please review/super-review the patch (will send a separate mail). thanks.
Whiteboard: [nsbeta1+] working on patch → [nsbeta1+] patch ready, in review process
Comment 17•24 years ago
|
||
looks good, sr=sspitzer
Comment 18•24 years ago
|
||
The diffs look good. Aorry about the delayed review. I guess you are using 0.8.1
build and it is fine, but in the latest builds, you would have to change all
menuitem value= to menuitem label= to make this a valid patch.
r= gayatrib
Updated•24 years ago
|
Whiteboard: [nsbeta1+] patch ready, in review process → [nsbeta1+] patch ready, in review process (relnote 0.8.1)
Assignee | ||
Comment 19•24 years ago
|
||
Updating the status whiteboard to reflect the finished reviews and the testing I
did on mailnews menus with this patch.
I just spoke to Asa. He is in the process of final round testing for 081 bits.
So, if he finds some regression/problem that must be fixed, then this bug has a
chance to get in. thanks to Asa for the info.
Also, there is another bug (72242) where one of the hewitt's modern skin changes
got onto the trunk and missed 081 branch. It is very simple I would like to get
that one also in, if we have a chance.
Anyway, Asa already added relnote 0.8.1 update to the status whiteboard here.
Will do the same for bug 72242 also.
Whiteboard: [nsbeta1+] patch ready, in review process (relnote 0.8.1) → [nsbeta1+] reviewed and tested (relnote 0.8.1)
Comment 20•24 years ago
|
||
*** Bug 73454 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 21•24 years ago
|
||
*** This bug has been marked as a duplicate of 72498 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Comment 23•23 years ago
|
||
*** Bug 72594 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•