Composer's Selection List Properties dialog appears with a XML parsing error

VERIFIED FIXED in mozilla1.4final

Status

SeaMonkey
Composer
--
major
VERIFIED FIXED
15 years ago
14 years ago

People

(Reporter: Chris Petersen, Assigned: jag (Peter Annema))

Tracking

Trunk
mozilla1.4final

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

365 bytes, text/html
Details
27.49 KB, patch
jag (Peter Annema)
: review+
Alec Flett
: superreview+
Details | Diff | Splinter Review
5.49 KB, patch
jag (Peter Annema)
: review+
(not reading, please use seth@sspitzer.org instead)
: superreview+
(not reading, please use seth@sspitzer.org instead)
: approval1.4+
Details | Diff | Splinter Review
(Reporter)

Description

15 years ago
Build: 2003-05-07-03
Platform: All
Expected Results: Selection List Properties Dialog should appear with correct
content
What I got: XML parser error (undefined entity)

Location: chrome://editor/content/EdSelectProps.xul
Line Number 78, Column 83: 

<label control="SelectName" value="&SelectName.label;"
accesskey="&SelectName.accesskey;" />



Steps to reproduce:

1) Open the attached test case which contains the select element in Composer
2) Place focus on the select element 
3) Choose Selection List Properties from the Format menu.
4) Notice XML parser in dialog.
(Reporter)

Updated

15 years ago
Severity: normal → major
Keywords: nsbeta1, regression
(Reporter)

Comment 1

15 years ago
Created attachment 122884 [details]
Select element
(Reporter)

Comment 2

15 years ago
Looks like this has been broken on the trunk for months. The oldest trunk build
on  windows I can locate is 2003-02-02-04. The problem is occuring in this build
so I'm not able to track the regression any further.

Comment 3

15 years ago
-->jag
Assignee: composer → jaggernaut
Target Milestone: --- → mozilla1.4final

Comment 4

15 years ago
adt: nsbeta1+/adt1
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt1]

Comment 5

15 years ago
This broke on 05 Oct 2002 13:44 when cmanske checked in some fixes for me.
The rest of the fixes are in the patch in bug 45495.
Depends on: 45495

Comment 6

15 years ago
Neil--we really don't want to ship 1.4 with this regression; is there anyway we
can remove the dependency on bug 45495?  Can you split up the patch enough to
address this specific issue?

Comment 7

15 years ago
Created attachment 123274 [details] [diff] [review]
Just the access key changes

This is attachment 109104 [details] [diff] [review] but with all the code changes removed.
/me wonders if alecf's sr= still applies...
(Assignee)

Comment 8

15 years ago
Comment on attachment 123274 [details] [diff] [review]
Just the access key changes

r=jag. Let's find out if sr=alecf applies :-)
Attachment #123274 - Flags: superreview?(alecf)
Attachment #123274 - Flags: review+

Comment 9

15 years ago
Comment on attachment 123274 [details] [diff] [review]
Just the access key changes

sr=alecf
Attachment #123274 - Flags: superreview?(alecf) → superreview+

Comment 10

15 years ago
Comment on attachment 123274 [details] [diff] [review]
Just the access key changes

This low risk patch fixes some localization issues in editor form element
dialogs.
Attachment #123274 - Flags: approval1.4?
we're past a l10n freeze for 1.4.

This is the minimal patch needed to fix the XML error?

jag, to reduce perceived risk, and get l10n approval, can you come up with a
minimal patch, one that just defines the missing accesskey?

(or, if we get rejected due to l10n changes, we could also remove
accesskey="&SelectName.accesskey;" for 1.4 final.  and then, for 1.5, land the
entire patch, with all the new accesskeys)

also, looking at the patch:

 <!ENTITY EditLegendText.label "Edit Legend:">
+<!ENTITY EditLegendText.accesskey "T">

shouldn't that be "t", instead of "T"?
Comment on attachment 123274 [details] [diff] [review]
Just the access key changes

this seems right for 1.5, can we get a minimal patch for 1.4 final?
Attachment #123274 - Flags: approval1.4?

Comment 13

15 years ago
Created attachment 123890 [details] [diff] [review]
Patch for branch only

If previous patch can't go on the trunk, this might work for the branch,
although I haven't tested it.
(Assignee)

Updated

15 years ago
Attachment #123890 - Flags: superreview?(sspitzer)
Attachment #123890 - Flags: review+
(Assignee)

Comment 14

15 years ago
Tested, works fine.
Comment on attachment 123890 [details] [diff] [review]
Patch for branch only

sorry for the delay, sr/a=sspitzer

thanks neil (and jag)

I'll let you guys decide to open a new bug or not, for 1.5
Attachment #123890 - Flags: superreview?(sspitzer)
Attachment #123890 - Flags: superreview+
Attachment #123890 - Flags: approval1.4+
(Assignee)

Comment 16

15 years ago
Comment on attachment 123890 [details] [diff] [review]
Patch for branch only

I've just checked in this patch. Once 1.5 opens this can be backed out and
replaced by the previous patch that does the better thing.
(Assignee)

Comment 17

15 years ago
Removing keywords to get this off the radar.
Keywords: nsbeta1+, regression
Whiteboard: [adt1]

Comment 18

15 years ago
Previous patch checked in as part of bug 45495.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Reporter)

Comment 19

15 years ago
Verified on the Macho (2003-05-29-08) and win32 (2003-05-27-08) trunk builds.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.