MozillaZine

Electrolysis: A tale of tab switching and themes

Discuss application theming and theme development.
mcdavis

User avatar
 
Posts: 3195
Joined: December 9th, 2005, 5:51 am

Post Posted June 10th, 2015, 4:58 am

This was posted for us (and others). Thanks to the author, George Wright.

http://www.hackermusings.com/2015/06/el ... nd-themes/
Last edited by mcdavis on June 10th, 2015, 4:57 pm, edited 1 time in total.
Theme Development is Radical Participation.
NNL Beta Builds for Current and Up-coming Firefox
Dear User: Your Help is Needed

ShareBird

User avatar
 
Posts: 2740
Joined: December 8th, 2004, 7:09 am
Location: Berlin | Made in Brasil

Post Posted June 10th, 2015, 12:36 pm

Yeah... I saw the new attribute a couple days ago. I'm wondering if we get negative effects doing something like :
.tabbrwoser-tab[selected], .tabbrowser-tab[visuallyselected]{}
???
Silvermel - A Theme for Firefox and Thunderbird
YATT - Yet Another Theme Tutorial
Don't give a man a fish. Teach him how to fish instead.

ShareBird

User avatar
 
Posts: 2740
Joined: December 8th, 2004, 7:09 am
Location: Berlin | Made in Brasil

Post Posted June 10th, 2015, 1:22 pm

ShareBird wrote:Yeah... I saw the new attribute a couple days ago. I'm wondering if we get negative effects doing something like :
.tabbrwoser-tab[selected], .tabbrowser-tab[visuallyselected]{}
???


And I guess yes... Since the selected attribute will be set earlier than visuallyselected (300ms before, AFAIK) the effect will be the same if we don't use the [visuallyselected] selector. For compatibility we can use:
Code: Select all
.tabbrwoser-tab:not([visuallyselected])[selected],
.tabbrowser-tab[visuallyselected] {
}


I think...
Silvermel - A Theme for Firefox and Thunderbird
YATT - Yet Another Theme Tutorial
Don't give a man a fish. Teach him how to fish instead.

patrickjdempsey

User avatar
 
Posts: 23734
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC

Post Posted June 10th, 2015, 3:42 pm

How silly. For backwards compatibility they should have named the final state [selected] and the "on hold" state as something like [selecting] or [selectionpending] if for some reason you would want to do that. But I don't know why you would want the tab to change before it's actually changing, especially if you already have a :hover state. Also not sure how there being a delay in tab switching is an "improvement" in behavior that's worth the 5 years they've been working on this.
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/

mcdavis

User avatar
 
Posts: 3195
Joined: December 9th, 2005, 5:51 am

Post Posted June 12th, 2015, 2:23 pm

This must be Bug 1066531 - [e10s] Switching tabs can result in old content being displayed for a split second after the tab bar is updated.
Theme Development is Radical Participation.
NNL Beta Builds for Current and Up-coming Firefox
Dear User: Your Help is Needed

mcdavis

User avatar
 
Posts: 3195
Joined: December 9th, 2005, 5:51 am

Post Posted June 16th, 2015, 3:31 pm

ShareBird, what you said looks right to me.

For the record, here's where the spinner that gw280 mentioned got added. It's applied with content CSS, but the spinner itself is in-theme.

(2014-10-24) (Fx36) Bug 1049551 - add a tab delay spinner for when we can't redraw tabs fast enough (white/black/garbage frame seen when switching between tabs with e10s)
Theme Development is Radical Participation.
NNL Beta Builds for Current and Up-coming Firefox
Dear User: Your Help is Needed

mcdavis

User avatar
 
Posts: 3195
Joined: December 9th, 2005, 5:51 am

Post Posted June 16th, 2015, 3:41 pm

I guess what they did was change the semantics of the term selected, internally, in Firefox code, and chose for the attribute [selected] to use that new semantics, keeping them from having to change almost every instance of tab.selected in JS/C++; without having to touch it, most of the existing code matched the new semantics.
Theme Development is Radical Participation.
NNL Beta Builds for Current and Up-coming Firefox
Dear User: Your Help is Needed

mcdavis

User avatar
 
Posts: 3195
Joined: December 9th, 2005, 5:51 am

Post Posted June 16th, 2015, 3:54 pm

I don't think anything has to be done here for Fx39 browsertabs because E10S isn't present there any more. While [visuallyselected] is present in Fx39, without E10S, both [selected] and [visuallyselected] get set at the same time (or at least within the same UI redraw cycle), and for Fx39 only you can either just keep on using [selected] or test [visuallyselected].

What does this mean for tabs other than browsertabs, like tabs in a plain old tabbox? I see some changes for that, but then why wasn't there anything for devtools?
Theme Development is Radical Participation.
NNL Beta Builds for Current and Up-coming Firefox
Dear User: Your Help is Needed

mcdavis

User avatar
 
Posts: 3195
Joined: December 9th, 2005, 5:51 am

Post Posted June 17th, 2015, 7:53 am

So I'm going to use [visuallyselected] for browsertabs only, and not for other kinds of tabs, because that's the minimal impacting change that meets all the requirements as far as I can tell.

The default theme uses [visuallyselected] in tabbox.css, but that's not mandatory since in all tabs other than browsertabs [visuallyselected] and [selected] always have the same value (or if there is a difference for a time, it's imperceptible and doesn't matter). They only differ in value with browsertabs with E10S for web pages rendered as remote content/a separate process.

Tabs in devtools also have the [visuallyselected] attribute but the default theme CSS doesn't use it there. I don't know why they did for tabbox.css but not devtools tabs; maybe that would have been crossing organizational boundaries so it didn't happen. Regardless, I'm not using [visuallyselected] for devtools either -- just for browsertabs. I think that's right.
Theme Development is Radical Participation.
NNL Beta Builds for Current and Up-coming Firefox
Dear User: Your Help is Needed

ShareBird

User avatar
 
Posts: 2740
Joined: December 8th, 2004, 7:09 am
Location: Berlin | Made in Brasil

Post Posted June 17th, 2015, 9:46 am

I would do the same. Notice that my proposed code doesn't work. We need the chrome.manifest flags to target Firefox versions if we want to offer compatibility.
Silvermel - A Theme for Firefox and Thunderbird
YATT - Yet Another Theme Tutorial
Don't give a man a fish. Teach him how to fish instead.

mcdavis

User avatar
 
Posts: 3195
Joined: December 9th, 2005, 5:51 am

Post Posted June 17th, 2015, 12:10 pm

ShareBird wrote:Notice that my proposed code doesn't work. We need the chrome.manifest flags to target Firefox versions if we want to offer compatibility.


Yeah, I see it now. [visuallyselected] can't be used to distinguish browser versions because it's not always present on browsertabs in Fx39, not until they're ready to render or the 300ms limit is hit.
Theme Development is Radical Participation.
NNL Beta Builds for Current and Up-coming Firefox
Dear User: Your Help is Needed

Return to Theme Development


Who is online

Users browsing this forum: No registered users and 1 guest