xul select1 + output testcase fails on updated branch

RESOLVED FIXED

Status

Core Graveyard
XForms
RESOLVED FIXED
10 years ago
11 months ago

People

(Reporter: aaronr, Assigned: aaronr)

Tracking

({fixed1.8.0.12, fixed1.8.1.4})

Trunk
x86
Windows XP
fixed1.8.0.12, fixed1.8.1.4

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

1.54 KB, application/vnd.mozilla.xul+xml
Details
920 bytes, patch
surkov
: review+
Doron Rosenberg (IBM)
: review+
Details | Diff | Splinter Review
(Assignee)

Description

10 years ago
Due to changes on the trunk that will go into 0.8, this testcase will fail.

1) The select1 is too thin when there is no default item selected.  This is due to a change from a patch for bug 370551.
2) The output bound to the same node as the select1 won't show the selected value.
(Assignee)

Comment 1

10 years ago
Created attachment 261105 [details]
testcase

Comment 2

10 years ago
(In reply to comment #0)
> Due to changes on the trunk that will go into 0.8, this testcase will fail.
> 
> 1) The select1 is too thin when there is no default item selected.  This is due
> to a change from a patch for bug 370551.
> 2) The output bound to the same node as the select1 won't show the selected
> value.
> 

Did you point correct bug number?
(Assignee)

Comment 3

10 years ago
Created attachment 261127 [details] [diff] [review]
patch

fixes the select1 in xul problem.  I don't know what to do about the output issue.  It has to be related to xbl somehow since the contained textnode has the correct value when you look at it in the DOM, but I can't create a simple non-xforms testcase that recreates the problem.  Everything I've tried ends up working.  And using a timeout so that we aren't setting the text node contents during construction doesn't help, either.  This was broken in 0.7 and no one complained about it and it works fine on the trunk, so I don't want to spend any more time on it now.  Maybe once 0.8 ships someone will have more time to track down the issue.  XBL guys probably wouldn't fix it on the branches anyhow, but might give us a nice workaround if we can narrow down the issue.
Attachment #261127 - Flags: review?(surkov.alexander)

Comment 4

10 years ago
Comment on attachment 261127 [details] [diff] [review]
patch

>Index: resources/content/xforms.css

>-xul|box.xf-value {
>+range xul|box.xf-value {
>   -moz-box-align: end;
>   -moz-box-orient: horizontal;
> }

I would rather move this style into skin/range-xul.css file. But it's up to you. In your patch I would add xul|*:root for that style rule.
Attachment #261127 - Flags: review?(surkov.alexander) → review+
(Assignee)

Comment 5

10 years ago
(In reply to comment #4)
> (From update of attachment 261127 [details] [diff] [review])
> >Index: resources/content/xforms.css
> 
> >-xul|box.xf-value {
> >+range xul|box.xf-value {
> >   -moz-box-align: end;
> >   -moz-box-orient: horizontal;
> > }
> 
> I would rather move this style into skin/range-xul.css file. But it's up to
> you. In your patch I would add xul|*:root for that style rule.
> 

I can move the change, sure.  But this rule applies to xhtml and xul both.  Remember that our spin ranges are the same in both.
(Assignee)

Updated

10 years ago
Attachment #261127 - Flags: review?(doronr)

Comment 6

10 years ago
(In reply to comment #5)

> I can move the change, sure.  But this rule applies to xhtml and xul both. 
> Remember that our spin ranges are the same in both.
> 

Ah, sorry, never mind then.

Updated

10 years ago
Attachment #261127 - Flags: review?(doronr) → review+
(Assignee)

Comment 7

10 years ago
checked into trunk.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Whiteboard: xf-to-branch
(Assignee)

Comment 8

10 years ago
checked into 1.8 branch on 2007-04-12
checked into 1.8.0 branch on 2007-04-16
Keywords: fixed1.8.0.12, fixed1.8.1.4
Whiteboard: xf-to-branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.