Last Comment Bug 376989 - xul select1 + output testcase fails on updated branch
: xul select1 + output testcase fails on updated branch
Status: RESOLVED FIXED
: fixed1.8.0.12, fixed1.8.1.4
Product: Core Graveyard
Classification: Graveyard
Component: XForms (show other bugs)
: Trunk
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: aaronr
: Stephen Pride
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-09 23:52 PDT by aaronr
Modified: 2016-07-15 14:46 PDT (History)
1 user (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
testcase (1.54 KB, application/vnd.mozilla.xul+xml)
2007-04-09 23:54 PDT, aaronr
no flags Details
patch (920 bytes, patch)
2007-04-10 02:48 PDT, aaronr
surkov.alexander: review+
doronr: review+
Details | Diff | Splinter Review

Description aaronr 2007-04-09 23:52:58 PDT
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.
Comment 1 aaronr 2007-04-09 23:54:31 PDT
Created attachment 261105 [details]
testcase
Comment 2 alexander :surkov 2007-04-09 23:57:18 PDT
(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?
Comment 3 aaronr 2007-04-10 02:48:30 PDT
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.
Comment 4 alexander :surkov 2007-04-10 03:44:44 PDT
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.
Comment 5 aaronr 2007-04-10 11:59:59 PDT
(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.
Comment 6 alexander :surkov 2007-04-10 19:59:23 PDT
(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.
Comment 7 aaronr 2007-04-11 12:26:07 PDT
checked into trunk.
Comment 8 aaronr 2007-04-23 16:42:04 PDT
checked into 1.8 branch on 2007-04-12
checked into 1.8.0 branch on 2007-04-16

Note You need to log in before you can comment on or make changes to this bug.