980007 - Make the opacity of non-removable items transition after entering customization mode

Status: RESOLVED WONTFIX

(Firefox :: Theme, defect)

Description

[Mike Conley (:mconley) (:⚙️)]

Bug 963999 did a lot of work to make the start and end state of the customize mode transition less jarring.

One thing that didn't get done was making the non-removable elements (like the URL bar container) opaque at the start of the transition, as opposed to the end. This was for performance reasons - see https://bugzilla.mozilla.org/show_bug.cgi?id=963999#c36 for details.

phlsa had the idea that we might try transitioning the opacity of those non-removable items at the end of the transition. So let's try that.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

After talking to jaws, I think we're P4'ing this until we get some of our P2's and P3's out of the way.

Comment 2

[Blake Winton (:bwinton) (:☕️)]

(I could mentor this one.)

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Blake Winton (:bwinton) from comment #2)
> (I could mentor this one.)

Can you place some initial steps as to how a new contributor can approach this bug? Things such as what files and where the changes need to be made would be helpful.

Comment 4

[Blake Winton (:bwinton) (:☕️)]

The file and line to change is https://dxr.mozilla.org/mozilla-central/source/browser/base/content/browser.css#312
The previous attempt at this was at https://bug963999.bugzilla.mozilla.org/attachment.cgi?id=8383900
We'll want to do something similar to the first change there:
    -toolbarpaletteitem[removable="false"] {
    +#main-window[customizing] toolbaritem[removable="false"] {
only not using "customizing".

Comment 5

[John Tungul]

what would we need to put in place of customizing?

Comment 6

[Avijit Gupta]

Attachment: Patch

changes made as proposed in comment #4

Comment 7

[Blake Winton (:bwinton) (:☕️)]

Thanks for the patch Avijit!  I've applied it to my copy of Firefox, and am rebuilding now to see how well it works.  The next step will be for you to set the r? flag on the patch, and ask :florian to review it.

Comment 8

[Blake Winton (:bwinton) (:☕️)]

Okay, so I built it, and it looks like with this change the urlbar and menu button are always disabled, which isn't exactly what we want.  ;)

So, instead of transitioning on [customizing], we should wait for [customize-entered], and we will also need to transition the opacity over, let's say, 150ms for all the toolbaritem which aren't removable.

We probably also want the opacity: 0.5 to apply on [customize-exiting], so that we wait for the exit transition to finish before fading back in, to avoid slowing the exit transition down.

Comment 9

[Blake Winton (:bwinton) (:☕️)]

Hi Avijit!

Are you still working on this bug?  Is there any way I can help you make progress on it?

Thanks,
Blake.

Comment 10

[Avijit Gupta]

(In reply to Blake Winton (:bwinton) from comment #9)
> Hi Avijit!
> 
> Are you still working on this bug?  Is there any way I can help you make
> progress on it?
> 
> Thanks,
> Blake.

Hey Blake, 
I am currently unable to make progress on this bug due to the ongoing exams in my institute. But i will definitely report back to you within a week or so.

Comment 11

[Vaibhav Bhosale]

Hey Blake,
I would like to work on this bug. But going through the above comments, I could not exactly figure out what needs to be done. Can you help me with that?

Comment 12

[Blake Winton (:bwinton) (:☕️)]

Hi Vaibhav!

So, comment #4 shows the outline of the change, and comment #8 goes into a little more specific detail.  Does that help?  If you have any questions about those two comments, I'ld be happy to answer them.  :)

Comment 13

[Martinho Aragão]

Mind if I jump in on this?

I've also identified that the customization border covers the urlbar. As it doesn't cover the menu bar, wouldn't it be better to have a customization box on the left and right of it, that way ensuring it's obvious those are 2 of the places one can move around tools? From what I saw, this is in the platform specific css?

If someone can explain aswell, I have not quite understood why using [customizing] caused a regression because the compares.talos from https://bugzilla.mozilla.org/show_bug.cgi?id=963999#c36 are deprecated.

As a sum up of this bug, the goal is to speed up the animation by applying opacity at the same time as the customization border and additional tools and features?

Comment 14

[Blake Winton (:bwinton) (:☕️)]

Please do!  (I'm afraid I'm away for the next couple of weeks, but hopefully Mike Conley can help you out!)

The goal of this bug is to make the transition to customization mode a little smoother, by animating the opacity of the non-removable items after everything has shifted in.  (We would animate them at the same time, but that ends up being more work than we can smoothly handle, if I remember correctly.)

Thanks!

Comment 15

[Martinho Aragão]

Attachment: Attempt to smooth out opacity transition

I've changed it from the browser.css to customizeMode.inc.css as that's where most of the code regarding this view is. 

I'd prefer if I managed to transition the opacity together with the customization-palette, but it seems that has something to do with when the "[showing="true"]" is applied, and so I couldn't see a proper way of getting it done. Any tips regarding this part would be welcome!

Comment 16

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8642463 [details] [diff] [review]
Attempt to smooth out opacity transition

Review of attachment 8642463 [details] [diff] [review]:
-----------------------------------------------------------------

Hey Martinho! Thanks for the patch - looking at it now.

Comment 17

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8642463 [details] [diff] [review]
Attempt to smooth out opacity transition

Review of attachment 8642463 [details] [diff] [review]:
-----------------------------------------------------------------

Hey Martinho, thanks for the patch!

::: browser/themes/shared/customizableui/customizeMode.inc.css
@@ +57,5 @@
> +  cursor: default;
> +}
> +
> +toolbaritem[removable="false"] {
> +  transition: opacity 0.15s ease-in-out;

One of the problems here is with the URL bar. The URL bar is one of the items in the customizable toolbar that is "wrapped" in a toolbarpaletteitem in order to prevent it from being interactive. The wrapping involves us creating a toolbarpaletteitem, inserting the toolbaritem inside of it, and then putting the toolbarpaletteitem in the spot that the toolbaritem used to be.

Doing so is, essentially, removing the toolbaritem from the DOM, and then re-adding it underneath the toolbarpaletteitem.

By the time the URL bar is wrapped, the transition has already been completed, so the customize-entered attribute is set on the document element.

Then we do the wrapping, which removes and re-adds the URL bar.

As soon as the URL bar is removed, any transition that was going to start is cancelled. Re-adding the item to the DOM causes us to match all of the final conditions for setting opacity to 0.5, but because the node is being re-added to the DOM, we don't transition it, and just cause it to be 0.5 immediately.

The end result being that, regardless of the set duration, the URL bar and any other non-removable toolbar items will not transition smoothly - they will blink straight to the 0.5 opacity.

What we might want to do instead is, when we also set the "showing" attribute to "true" on the palette, also set a "wrapped" attribute to "true" on each toolbar, and via that rule, do the transition.

The place I'd look at is in browser/components/customizableui/CustomizeMode.jsm, in the enter function - deep in there, within a setTimeout, we set showing to "true" on the palette. Perhaps this is where you can also set the toolbar attributes (we'll also need to remove them in the exit function).

Worth trying, anyhow. Let me know if you have any questions!

Comment 18

[Martinho Aragão]

Attachment: Smoothen non-removable toolbaritems transition

Indeed, I had thought of applying a new attribute through the .jsm files, but felt there had to be a better way, I was wrong indeed.

From what I saw this is what we were looking for, yet somehow there's a delay before the start of customization-entered that I wish could be shortened. 

And thank you so much for all the information! Is there anything missing now?

Comment 19

[Mike Conley (:mconley) (:⚙️)]

Hey - I'm about to go on extended PTO. Seeing if jaws can help drive this over the line.

Comment 20

[obongofon]

Hello, can you assign me this bug to work on as I am new to open source.

Comment 21

[Blake Winton (:bwinton) (:☕️)]

Hi Obongofon!  I think we should let Martinho (or Jared, or Mike) comment as to whether they're still working on it before we give it to someone else…  But check back in a week or two, and see if it's still unclaimed.

Thanks!

Comment 22

[Martinho Aragão]

Hey!

I'm still around here, but dunno if there is anything missing from the latest attachment I sent. Although if obongofon wants to take over this, I have no problem at all.

Comment 23

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8649423 [details] [diff] [review]
Smoothen non-removable toolbaritems transition

Review of attachment 8649423 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for your patch, and sorry this languished for so long. :(

Let me know if you have any questions about what I wrote - happy to talk it through. If you get a new patch up, can you set the review flag on it to my email address? That way it'll go into my queue and I won't miss it.

::: browser/components/customizableui/CustomizeMode.jsm
@@ +281,5 @@
>  
>        // Show the palette now that the transition has finished.
>        this.visiblePalette.hidden = false;
>        window.setTimeout(() => {
> +        let toolbaritems = document.querySelectorAll("toolbaritem[removable=false]");

In https://bugzilla.mozilla.org/show_bug.cgi?id=980007#c17, I suggested setting a wrapped attribute on the toolbar itself (as opposed to the individual items within the toolbar). Is that possible instead, since that'd involve less DOM manipulation in general.

Comment 24

[Pas]

Hi, I am new to fixing bugs and I would like to work on the bug please.

Comment 25

[Ivan]

I will try to produce a patch for this bug and submit it for some feedback i understand what I need to do.  Thank you

Comment 26

[obongofon]

I will put up a patch soon for this bug.

Comment 27

[Babatunde Salaam]

Attachment: smoothen.patch

was looking at this bug and am interested in it 
following the the comment17 i have created a patch for you to check

Comment 28

[Blake Winton (:bwinton) (:☕️)]

Thank you for your offers, everyone, but I think we should let Martinho continue with the bug for a little while longer.  It feels like he's close, and it would be nice to let him finish it up.  :)

Comment 29

[Pas]

Attachment: smoothen.patch

Hi, This is the patch I created for the Smoothen task.

Comment 30

[Jared Wein [:jaws] (please needinfo? me)]

Probably should figure out some more structured next steps here, either picking up from Martinho's patch which still needs more work (comment #23) or starting anew with a different approach.

Comment 31

[Blake Winton (:bwinton) (:☕️)]

It still seems to me like Martinho's patch is a reasonable approach, so I think the next step would be for someone to pick it up, fix the things mentioned in comment #23, and ask mconley for another review.

Mike, does that sound reasonable to you?

Comment 32

[Mike Conley (:mconley) (:⚙️)]

(In reply to Blake Winton (:bwinton) (:☕️) from comment #31)
> It still seems to me like Martinho's patch is a reasonable approach, so I
> think the next step would be for someone to pick it up, fix the things
> mentioned in comment #23, and ask mconley for another review.
> 
> Mike, does that sound reasonable to you?

Yes.

Comment 33

[Matt O'Connor [:mattoc]]

Hi, can someone assign me to this bug please.

Comment 34

[Sae-Lynn Yi]

Hello, I would like to work on this bug and I plan on submitting a patch by February 26. My plan is to work on Mike Conley's suggestions for wrapping the toolbar (as mentioned in comment #23). Please let me know if there are updates or any recent information I should be aware of. Thank you!

Comment 35

[Mike Conley (:mconley) (:⚙️)]

Hey Sae-Lynn Yi! Sounds good to me. I'm setting the needinfo flag to make sure your mentor is aware. Thanks!

Comment 36

[Blake Winton (:bwinton) (:☕️)]

Sounds good to me too.  Thanks for picking this up!

Comment 37

[Sae-Lynn Yi]

Attachment: comment23.patch

Attempt at implementing suggestions made by Mike Conley in comment #23.

Comment 38

[Sae-Lynn Yi]

Good morning.

Thank you for assigning me this bug.

I've uploaded my attempt at setting a wrapped attribute as suggested by Mike Conley in comment #23.
My concern is that I did not set the wrapped attribute on the correct element. 
Since the URL bar is wrapped in a toolbarpaletteitem with attribute place="toolbar", I set the wrapped attribute on that. 

I've also removed this attribute upon exit as suggested in comment #17 by Mike Conley. 

When Mike Conley said in comment #17 : "set a "wrapped" attribute to "true" on each toolbar, and via that rule, do the transition." I took that as making the following changes to the css file as seen in my patch. 

Please let me know your thoughts. Thank you.

Comment 39

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8724036 [details] [diff] [review]
comment23.patch

Setting the review flag on myself so I can take a look at this. Thanks!

Comment 40

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8724036 [details] [diff] [review]
comment23.patch

Review of attachment 8724036 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for the patch, Sae-Lynn! This looks pretty good - but there are a few small problems with it. I've added some notes below. Let me know if you have any questions!

::: browser/components/customizableui/CustomizeMode.jsm
@@ +285,5 @@
>          // and make it async so it doesn't affect the timing.
>          this.visiblePalette.clientTop;
>          this.visiblePalette.setAttribute("showing", "true");
> +
> +        let toolbars = document.querySelectorAll("toolbarpaletteitem");

This is actually not selecting the toolbars, but the items within the toolbars that are wrapped.

There's a collection of toolbars that we gathered earlier in the containing function that we can probably re-use instead: https://dxr.mozilla.org/mozilla-central/rev/5e0140b6d11821e0c2a2de25bc5431783f03380a/browser/components/customizableui/CustomizeMode.jsm#307

We gather the same type of collection in the exit method, and can probably remove the "wrapped" state here:

https://dxr.mozilla.org/mozilla-central/rev/5e0140b6d11821e0c2a2de25bc5431783f03380a/browser/components/customizableui/CustomizeMode.jsm#517

@@ +287,5 @@
>          this.visiblePalette.setAttribute("showing", "true");
> +
> +        let toolbars = document.querySelectorAll("toolbarpaletteitem");
> +        for (let toolbar of toolbars)
> +        toolbar.setAttribute("wrapped", "true");

For-loops should have their contents wrapped in braces and indented.

@@ +375,5 @@
>      this.visiblePalette.removeAttribute("showing");
>      this.paletteEmptyNotice.hidden = true;
>  
> +    let toolbars = document.querySelectorAll("toolbarpaletteitem");
> +    for (let toolbar of toolbars)

Same as above, re: for-loops.

Comment 41

[Sae-Lynn Yi]

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #40)
> Comment on attachment 8724036 [details] [diff] [review]
> comment23.patch
> 
> Review of attachment 8724036 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Thanks for the patch, Sae-Lynn! This looks pretty good - but there are a few
> small problems with it. I've added some notes below. Let me know if you have
> any questions!
> 
> ::: browser/components/customizableui/CustomizeMode.jsm
> @@ +285,5 @@
> >          // and make it async so it doesn't affect the timing.
> >          this.visiblePalette.clientTop;
> >          this.visiblePalette.setAttribute("showing", "true");
> > +
> > +        let toolbars = document.querySelectorAll("toolbarpaletteitem");
> 
> This is actually not selecting the toolbars, but the items within the
> toolbars that are wrapped.
> 
> There's a collection of toolbars that we gathered earlier in the containing
> function that we can probably re-use instead:
> https://dxr.mozilla.org/mozilla-central/rev/
> 5e0140b6d11821e0c2a2de25bc5431783f03380a/browser/components/customizableui/
> CustomizeMode.jsm#307
> 


Thank you for the in-depth response and assistance, Mike Conley.
So now I am getting confused about what it is we want to smoothly transition.
Before, I had understood it as "transition the opacity of the browser toolbar, the rectangle that encapsulates the URL bar". But when I changed the code according to your most recent suggestions in comment #40, I saw that the changes were applied to the tabs area, the rectangle right above the URL bar. So is it the URL bar or the tabs bar we are focusing on?


I'm trying to detect the differences in animation by recording the screen and comparing the clips side by side. However, I need to get a clear grasp of exactly what change I need to see. I would appreciate it if you would kindly re-clarify what effect I should be expecting. 

Here is small clip of what I understood the problem as: 
https://www.youtube.com/watch?v=A2JSXhAqMP4&feature=youtu.be
I *temporarily* set the background-color to black to highlight what I was focusing on. 

Thank you.

Comment 42

[Mike Conley (:mconley) (:⚙️)]

Thank you for the video, Sae-Lynn. Yes, something is wrong here with my suggestion. Let me tinker with it tomorrow, and I'll hopefully have an answer for you then!

Comment 43

[Mike Conley (:mconley) (:⚙️)]

(In reply to Sae-Lynn Yi from comment #41)
> (In reply to Mike Conley (:mconley) - Needinfo me! from comment #40)
> > Comment on attachment 8724036 [details] [diff] [review]
> > comment23.patch
> > 
> > Review of attachment 8724036 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > Thanks for the patch, Sae-Lynn! This looks pretty good - but there are a few
> > small problems with it. I've added some notes below. Let me know if you have
> > any questions!
> > 
> > ::: browser/components/customizableui/CustomizeMode.jsm
> > @@ +285,5 @@
> > >          // and make it async so it doesn't affect the timing.
> > >          this.visiblePalette.clientTop;
> > >          this.visiblePalette.setAttribute("showing", "true");
> > > +
> > > +        let toolbars = document.querySelectorAll("toolbarpaletteitem");
> > 
> > This is actually not selecting the toolbars, but the items within the
> > toolbars that are wrapped.
> > 
> > There's a collection of toolbars that we gathered earlier in the containing
> > function that we can probably re-use instead:
> > https://dxr.mozilla.org/mozilla-central/rev/
> > 5e0140b6d11821e0c2a2de25bc5431783f03380a/browser/components/customizableui/
> > CustomizeMode.jsm#307
> > 
> 
> 
> Thank you for the in-depth response and assistance, Mike Conley.
> So now I am getting confused about what it is we want to smoothly transition.
> Before, I had understood it as "transition the opacity of the browser
> toolbar, the rectangle that encapsulates the URL bar". But when I changed
> the code according to your most recent suggestions in comment #40, I saw
> that the changes were applied to the tabs area, the rectangle right above
> the URL bar. So is it the URL bar or the tabs bar we are focusing on?

It should be the URL bar, in this case. If you're not familiar with the Browser Toolbox, this tool might become useful for you to debug what's going on here:

https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox

(Specifically the Inspector tool and the Rules / Style Editor)

There's a toolbarpaletteitem that gets wrapped around the URL bar node during the latter part of the transition. What we're looking for is a CSS rule to be applied _after_ that wrapping occurs, since right now it occurs _before_ (and when a CSS transition is in effect, but the targeted DOM node is removed and re-inserted as we do when wrapping, then the transition skips to the end).

So that's the task - try to add an attribute that triggers the opacity transition after the wrapping occurs.

Does that clear things up? Please let me know if you have more questions!

Comment 44

[Sae-Lynn Yi]

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #43)
> (In reply to Sae-Lynn Yi from comment #41)
> > (In reply to Mike Conley (:mconley) - Needinfo me! from comment #40)
> > > Comment on attachment 8724036 [details] [diff] [review]
> > > comment23.patch
> > > 
> > > Review of attachment 8724036 [details] [diff] [review]:
> > > -----------------------------------------------------------------
> > > 
> > > Thanks for the patch, Sae-Lynn! This looks pretty good - but there are a few
> > > small problems with it. I've added some notes below. Let me know if you have
> > > any questions!
> > > 
> > > ::: browser/components/customizableui/CustomizeMode.jsm
> > > @@ +285,5 @@
> > > >          // and make it async so it doesn't affect the timing.
> > > >          this.visiblePalette.clientTop;
> > > >          this.visiblePalette.setAttribute("showing", "true");
> > > > +
> > > > +        let toolbars = document.querySelectorAll("toolbarpaletteitem");
> > > 
> > > This is actually not selecting the toolbars, but the items within the
> > > toolbars that are wrapped.
> > > 
> > > There's a collection of toolbars that we gathered earlier in the containing
> > > function that we can probably re-use instead:
> > > https://dxr.mozilla.org/mozilla-central/rev/
> > > 5e0140b6d11821e0c2a2de25bc5431783f03380a/browser/components/customizableui/
> > > CustomizeMode.jsm#307
> > > 
> > 
> > 
> > Thank you for the in-depth response and assistance, Mike Conley.
> > So now I am getting confused about what it is we want to smoothly transition.
> > Before, I had understood it as "transition the opacity of the browser
> > toolbar, the rectangle that encapsulates the URL bar". But when I changed
> > the code according to your most recent suggestions in comment #40, I saw
> > that the changes were applied to the tabs area, the rectangle right above
> > the URL bar. So is it the URL bar or the tabs bar we are focusing on?
> 
> It should be the URL bar, in this case. If you're not familiar with the
> Browser Toolbox, this tool might become useful for you to debug what's going
> on here:
> 
> https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox
> 
> (Specifically the Inspector tool and the Rules / Style Editor)
> 
> There's a toolbarpaletteitem that gets wrapped around the URL bar node
> during the latter part of the transition. What we're looking for is a CSS
> rule to be applied _after_ that wrapping occurs, since right now it occurs
> _before_ (and when a CSS transition is in effect, but the targeted DOM node
> is removed and re-inserted as we do when wrapping, then the transition skips
> to the end).
> 
> So that's the task - try to add an attribute that triggers the opacity
> transition after the wrapping occurs.
> 
> Does that clear things up? Please let me know if you have more questions!

Thank you so much for that, and it does clear up a lot of things! I found your recommendation of the Browser Toolbox very helpful and enjoyable to use! 

If we're just targeting the URL bar, wouldn't it be better to query select on "#urlbar-container" and check if it has "toolbarpaletteitem" as a parent (as a way of checking the wrapped part)? If that returns true, then we can set a wrapped attribute to that...Please let me know if I'm still understanding correctly. Thank you.

Comment 45

[Mike Conley (:mconley) (:⚙️)]

(In reply to Sae-Lynn Yi from comment #44)
> (In reply to Mike Conley (:mconley) - Needinfo me! from comment #43)
> > (In reply to Sae-Lynn Yi from comment #41)
> > > (In reply to Mike Conley (:mconley) - Needinfo me! from comment #40)
> > > > Comment on attachment 8724036 [details] [diff] [review]
> > > > comment23.patch
> > > > 
> > > > Review of attachment 8724036 [details] [diff] [review]:
> > > > -----------------------------------------------------------------
> > > > 
> > > > Thanks for the patch, Sae-Lynn! This looks pretty good - but there are a few
> > > > small problems with it. I've added some notes below. Let me know if you have
> > > > any questions!
> > > > 
> > > > ::: browser/components/customizableui/CustomizeMode.jsm
> > > > @@ +285,5 @@
> > > > >          // and make it async so it doesn't affect the timing.
> > > > >          this.visiblePalette.clientTop;
> > > > >          this.visiblePalette.setAttribute("showing", "true");
> > > > > +
> > > > > +        let toolbars = document.querySelectorAll("toolbarpaletteitem");
> > > > 
> > > > This is actually not selecting the toolbars, but the items within the
> > > > toolbars that are wrapped.
> > > > 
> > > > There's a collection of toolbars that we gathered earlier in the containing
> > > > function that we can probably re-use instead:
> > > > https://dxr.mozilla.org/mozilla-central/rev/
> > > > 5e0140b6d11821e0c2a2de25bc5431783f03380a/browser/components/customizableui/
> > > > CustomizeMode.jsm#307
> > > > 
> > > 
> > > 
> > > Thank you for the in-depth response and assistance, Mike Conley.
> > > So now I am getting confused about what it is we want to smoothly transition.
> > > Before, I had understood it as "transition the opacity of the browser
> > > toolbar, the rectangle that encapsulates the URL bar". But when I changed
> > > the code according to your most recent suggestions in comment #40, I saw
> > > that the changes were applied to the tabs area, the rectangle right above
> > > the URL bar. So is it the URL bar or the tabs bar we are focusing on?
> > 
> > It should be the URL bar, in this case. If you're not familiar with the
> > Browser Toolbox, this tool might become useful for you to debug what's going
> > on here:
> > 
> > https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox
> > 
> > (Specifically the Inspector tool and the Rules / Style Editor)
> > 
> > There's a toolbarpaletteitem that gets wrapped around the URL bar node
> > during the latter part of the transition. What we're looking for is a CSS
> > rule to be applied _after_ that wrapping occurs, since right now it occurs
> > _before_ (and when a CSS transition is in effect, but the targeted DOM node
> > is removed and re-inserted as we do when wrapping, then the transition skips
> > to the end).
> > 
> > So that's the task - try to add an attribute that triggers the opacity
> > transition after the wrapping occurs.
> > 
> > Does that clear things up? Please let me know if you have more questions!
> 
> Thank you so much for that, and it does clear up a lot of things! I found
> your recommendation of the Browser Toolbox very helpful and enjoyable to
> use! 
> 
> If we're just targeting the URL bar, wouldn't it be better to query select
> on "#urlbar-container" and check if it has "toolbarpaletteitem" as a parent
> (as a way of checking the wrapped part)? If that returns true, then we can
> set a wrapped attribute to that...Please let me know if I'm still
> understanding correctly. Thank you.

I think that's a brilliant suggestion - though instead of directly targeting #urlbar-container, we might want to target anything that doesn't have the removable attribute set to "true". Yes, let's give that a shot and see if it works.

Comment 46

[Sae-Lynn Yi]

Thanks for your approval! Currently I'm in the midst of job interviews, so I will get the patch in by this weekend.

Comment 47

[irina6793]

Hello,
Can I contribute in fixing this bug?

Comment 48

[Sae-Lynn Yi]

(In reply to irina6793 from comment #47)
> Hello,
> Can I contribute in fixing this bug?

Please do! Thanks!