Closed Bug 591147 Opened 10 years ago Closed 10 years ago

Let TabItem spacing used in Items.arrange be specified via CSS

Categories

(Firefox Graveyard :: Panorama, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 4.0b7

People

(Reporter: mitcho, Assigned: mitcho)

References

Details

(Whiteboard: [qa-])

Attachments

(1 file, 4 obsolete files)

The margin of TabItems should be used to compute the padding value in Items.arrange, used by GroupItems.arrange.
Attached patch Proposed patch (obsolete) — Splinter Review
Assignee: nobody → mitcho
Status: NEW → ASSIGNED
Attachment #469749 - Flags: review?(dolske)
Attachment #469749 - Flags: feedback?(ian)
Target Milestone: --- → Firefox 4.0b5
Attachment #469749 - Attachment is obsolete: true
Attachment #469759 - Flags: review?(dolske)
Attachment #469759 - Flags: feedback?(ian)
Attachment #469749 - Flags: review?(dolske)
Attachment #469749 - Flags: feedback?(ian)
Comment on attachment 469759 [details] [diff] [review]
Patch, with missing patches for gnomestripe and winstripe

Is this going to be a problem when we go to multiscale universe?  I should think we'd want to lay things out using padding that was agnostic to the current screen's pixels.  

I guess in general, we need to figure out how we can maintain this multiscale universe and lay everything out predictably, yet allow themers to re-style.
(In reply to comment #3)
> Comment on attachment 469759 [details] [diff] [review]
> Patch, with missing patches for gnomestripe and winstripe
> 
> Is this going to be a problem when we go to multiscale universe?  I should
> think we'd want to lay things out using padding that was agnostic to the
> current screen's pixels.  
> 
> I guess in general, we need to figure out how we can maintain this multiscale
> universe and lay everything out predictably, yet allow themers to re-style.

Indeed, that's a valid discussion (and I have some thoughts), but I think out of the scope of this requested patch.
Comment on attachment 469759 [details] [diff] [review]
Patch, with missing patches for gnomestripe and winstripe

(In reply to comment #4)
> Indeed, that's a valid discussion (and I have some thoughts), but I think out
> of the scope of this requested patch.

Fair enough.  I was just concerned it was a step backwards.
Attachment #469759 - Flags: feedback?(ian) → feedback+
Target Milestone: Firefox 4.0b5 → Firefox 4.0b6
Attachment #469759 - Flags: review?(dolske) → review?(dietrich)
Attachment #469759 - Flags: review?(dietrich)
Attachment #469759 - Flags: review+
Attachment #469759 - Flags: approval2.0+
Attached patch Patch for checkin (obsolete) — Splinter Review
Attachment #469759 - Attachment is obsolete: true
And backed out due to Moth test failures.
Attachment #471936 - Attachment is obsolete: true
the failure was a different bug, relanded:

http://hg.mozilla.org/mozilla-central/rev/1cf731410dc2
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
test failed again: http://pastebin.mozilla.org/783925

backed out: http://hg.mozilla.org/mozilla-central/rev/c3e21097bb78
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This patch applied on top of the patch in bug 592586 doesn't cause the test failures.
According to the try server results, this patch is causing the failures to occur.
My push to try yesterday of my patch for bug 591147 with updated tests to try to avert the timing (just using a setTimeout) came back with no test failures, suggesting that the fixes we're making now to the tests in bug 594213 should let this patch pass.
Updated for rot
Attachment #472412 - Attachment is obsolete: true
http://hg.mozilla.org/mozilla-central/rev/0a52a1cfd394
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [qa-]
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.