Using Windows 10 x86, Nightly 60.0a1 (2018-02-21) STR (for some reason this does not work on a clean profile, I had to use my personal profile with Mozregression to verify the regression range): 0. Open Nightly maximized, and in the meantime prepare other non-Firefox related window open, not maximized 1. Open many new tabs so the tab strip would really overflow 2. (While the tab strip is scrolled to the end) On the third tab from the last, go to any webpage 3. Switch to the other window 4. While this other window is in focus, click one of the visible tabs on the backgrounded Nightly AR: 1. After step 3, you can see that the tab strip auto-scrolls to the tab selected and focused on, on step 2 2. After step 4, the focused tab will not be the one you actually clicked, and it will be one of the first opened tabs- as if the autoscrolling mentioned in AR #1 actually scrolled the entire tab strip to the beggining (while displaying the set of tabs prior to the tab selected on step 2) ER: 1. No autoscrolling 2. Clicking the desired tab would actually open it Regression info from Mozregression: 2018-02-21T20:48:57: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=7a63a457c8e89edc417ea384f24102c988feb3d5&full=1 2018-02-21T20:48:59: DEBUG : Found commit message: Bug 1417138 part 2 - Enable stylo-chrome by default. r=bholley MozReview-Commit-ID: D19QBD4nqWf 2018-02-21T20:48:59: INFO : The bisection is done. 2018-02-21T20:48:59: INFO : Stopped See attached for screencast of the issue.

(In reply to Itiel from comment #0) > STR (for some reason this does not work on a clean profile, I had to use my > personal profile with Mozregression to verify the regression range): Are you able to check if e.g. the prefs in your profile cause this, or if it's something else? That would really help with reproducing and tracking this down...

(In reply to :Gijs from comment #1) > Are you able to check if e.g. the prefs in your profile cause this, or if > it's something else? That would really help with reproducing and tracking > this down... Investigating. I think it may be due to my profile being RTL, though I'm not sure if that relates to the issue.

Yep, I was right. Changing intl.uidirection in my profile from -1 to 0 immediately fixes the issue. No restart required. Reverting it back to -1 makes it reproducible again. One more issue using the exact same STR as above (and with having the mentioned pref set to RTL) is that after step 3, if you go back to Nightly _while clicking the page content area, and not the tab strip_, the domain highlighting feature on the URL bar will not be in effect and the _entire_ URL address will be black colored. So for the following URL: https://bugzilla.mozilla.org/show_bug.cgi?id=1440036 instead of having the "mozilla.org" part in black, and the rest in grey- all of the URL is in black.

Also, now with setting intl.uidirection to 1, I can reproduce it with a clean profile using Mozregression. And it leads to the same bug mentioned in the first comment here.

Could you run mozregression with the --pref layout.css.servo.chrome.enabled:true flag?

(In reply to Emilio Cobos Álvarez [:emilio] from comment #5) > Could you run mozregression with the --pref > layout.css.servo.chrome.enabled:true flag? ... with RTL disabled?

(In reply to Itiel from comment #6) > (In reply to Emilio Cobos Álvarez [:emilio] from comment #5) > > Could you run mozregression with the --pref > > layout.css.servo.chrome.enabled:true flag? > > ... with RTL disabled? Oh, with RTL enabled of course, given otherwise this bug doesn't seem reproducible.

2018-02-21T22:39:43: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=0238eee84c25b41e3582648d0cb4e84b0739a268&full=1 2018-02-21T22:39:44: DEBUG : Found commit message: Bug 1390694 - Part 5: Enable browser_windowactivation.js test. r=emilio MozReview-Commit-ID: 3q0KgAx0YWh 2018-02-21T22:39:44: INFO : The bisection is done. 2018-02-21T22:39:44: INFO : Stopped

[ Triage 2018/02/21: P3 ]

It looks like this is a regression from heycam's fix for -moz-window-inactive bug 1390694.

I don't think bug 1390694 is the underlying reason of that. I suspect this is a case where restyle causes something weird, and bug 1390694 just make the restyle happen at the right time.

I've tried to reproduce this without success with a 32-bit Hebrew Firefox nightly on windows 10 with a clean profile. When I alt-tab to windows explorer, or click the icon in the task tray, I don't get the shift in the tab strip in comment 3. Any further thoughts on how this might be reproduced?

(In reply to Bobby Holley (:bholley) from comment #12) > I've tried to reproduce this without success with a 32-bit Hebrew Firefox > nightly on windows 10 with a clean profile. > > When I alt-tab to windows explorer, or click the icon in the task tray, I > don't get the shift in the tab strip in comment 3. Any further thoughts on > how this might be reproduced? Heh, and here I thought I elaborated too much :) First of all, are you able to reproduce the third issue mentioned in comment 3, simply by minimizing the Nightly window to the taskbar and maximizing it back again? (for this issue forget the STR from my first comment; this is the easiest way to make the issue with the URL bar apparent) Minizing and maximizing also reproduces AR #1. For the first 2 issues mentioned in the first comment- after switching to the other application, did you click the tab itself directly (using a single mouse click), WITHOUT alt-tabing or clicking the content area etc.? (for that you need the other application's window to be small, so you can click the tab from beyond the other application's window using one mouse click only) Other than that.. not sure what else can be done. You can PM me if you'd like to see me in action via TeamViewer etc.

(In reply to Itiel from comment #13) > (In reply to Bobby Holley (:bholley) from comment #12) > > I've tried to reproduce this without success with a 32-bit Hebrew Firefox > > nightly on windows 10 with a clean profile. > > > > When I alt-tab to windows explorer, or click the icon in the task tray, I > > don't get the shift in the tab strip in comment 3. Any further thoughts on > > how this might be reproduced? > > Heh, and here I thought I elaborated too much :) > > First of all, are you able to reproduce the third issue mentioned in comment > 3, simply by minimizing the Nightly window to the taskbar and maximizing it > back again? (for this issue forget the STR from my first comment; this is > the easiest way to make the issue with the URL bar apparent) > Minizing and maximizing also reproduces AR #1. I didn't try that one - I can later, it just takes some time because I need to reboot my linux dev machine into windows. :-) Though realistically, if I don't see the first two issues, it seems unlikely that I'd see the third. > For the first 2 issues mentioned in the first comment- after switching to > the other application, did you click the tab itself directly (using a single > mouse click), WITHOUT alt-tabing or clicking the content area etc.? (for > that you need the other application's window to be small, so you can click > the tab from beyond the other application's window using one mouse click > only) Yeah, I did exactly that (similar to what I saw in the screen capture). > > Other than that.. not sure what else can be done. You can PM me if you'd > like to see me in action via TeamViewer etc. So to confirm: * This happens with today's nightly, hebrew language, 32-bit, on windows 10 * You're using a fresh profile, with no prefs modified If so I'm not sure what could be different between your setup and mine. Is your OS RTL? I wonder if that might affect things. Do you happen to have access to second machine? If so, are you able to reproduce this there as well?

(In reply to Bobby Holley (:bholley) from comment #14) > Though realistically, if I don't see the first two issues, it seems unlikely > that I'd see the third. What I meant was that if for some reason you're doing things a bit differently on your machine, simplifying the STR ( =minimizing and maximizing) would probably get similar results as I have. > So to confirm: > * This happens with today's nightly, hebrew language, 32-bit, on windows 10 > * You're using a fresh profile, with no prefs modified Yes for both. > If so I'm not sure what could be different between your setup and mine. Is > your OS RTL? I wonder if that might affect things. Yes, but I don't think this should affect this somehow. > Do you happen to have access to second machine? If so, are you able to > reproduce this there as well? Going to try now. Though that OS is LTR.

(In reply to Itiel from comment #15) > (In reply to Bobby Holley (:bholley) from comment #14) > > Though realistically, if I don't see the first two issues, it seems unlikely > > that I'd see the third. > > What I meant was that if for some reason you're doing things a bit > differently on your machine, simplifying the STR ( =minimizing and > maximizing) would probably get similar results as I have. Yeah, good point. :-) > > > So to confirm: > > * This happens with today's nightly, hebrew language, 32-bit, on windows 10 > > * You're using a fresh profile, with no prefs modified > > Yes for both. > > > If so I'm not sure what could be different between your setup and mine. Is > > your OS RTL? I wonder if that might affect things. > > Yes, but I don't think this should affect this somehow. > > > Do you happen to have access to second machine? If so, are you able to > > reproduce this there as well? > > Going to try now. Though that OS is LTR. Great! Very interested to hear the results.

(In reply to Itiel from comment #15) > > If so I'm not sure what could be different between your setup and mine. Is > > your OS RTL? I wonder if that might affect things. > > Yes, but I don't think this should affect this somehow. > > > Do you happen to have access to second machine? If so, are you able to > > reproduce this there as well? > > Going to try now. Though that OS is LTR. ... or maybe I'm wrong? Interestingly, non of the issues mentioned here are occuring in the other machine (using a clean profile), which is LTR-based (OS is in english). But on a Windows 7 x86 VM (which is in hebrew) I am able to reproduce all 3 issues (again, on a clean profile). 4th issue I can see here (regardless of OS language) that I didn't notice before is that on Nightly new startup, the New Tab button is on the left (not sticking to the New Tab on the right) and there are scrollers on each side of the tab strip (that's why a shading is visible on the right side of the tab). This can be 'fixed' by overflowing the tab strip and closing all of the new tabs but the first one.

(In reply to Itiel from comment #17) > (In reply to Itiel from comment #15) > > > If so I'm not sure what could be different between your setup and mine. Is > > > your OS RTL? I wonder if that might affect things. > > > > Yes, but I don't think this should affect this somehow. > > > > > Do you happen to have access to second machine? If so, are you able to > > > reproduce this there as well? > > > > Going to try now. Though that OS is LTR. > > ... or maybe I'm wrong? > Interestingly, non of the issues mentioned here are occuring in the other > machine (using a clean profile), which is LTR-based (OS is in english). > But on a Windows 7 x86 VM (which is in hebrew) I am able to reproduce all 3 > issues (again, on a clean profile). Ahah! That explains why I wasn't able to reproduce this before. > 4th issue I can see here (regardless of OS language) that I didn't notice > before is that on Nightly new startup, the New Tab button is on the left > (not sticking to the New Tab on the right) and there are scrollers on each > side of the tab strip (that's why a shading is visible on the right side of > the tab). This can be 'fixed' by overflowing the tab strip and closing all > of the new tabs but the first one. Does that behavior change when you toggle layout.css.servo.chrome.enabled?

(In reply to Bobby Holley (:bholley) from comment #18) > Does that behavior change when you toggle layout.css.servo.chrome.enabled? Yes, just tried. You should also be able to reproduce this too, I tested it on the LTR'ed OS machine.

It seems I can reproduce it reliably. For people whose OS is LTR, you just need to set intl.uidirection to "1" to get RTL UI on Firefox to reproduce this issue.

This is likely the same issue as bug 1440258, although the full flow causing this isn't completely clear to me. So what seems to happen is that, when the ui locale is rtl, we have an extra rule matched on :root: > :root:-moz-locale-dir(rtl) { > direction: rtl; > } and apparently direction property is a reframe property. This triggers reframe on <popupgroup> and <tooltip> due to bug 1440258. But why that reframe causes the tabstrip to scroll is unknown. If I add the following rule to xul.css: > popupgroup:-moz-locale-dir(rtl), > tooltip:-moz-locale-dir(rtl) { > direction: rtl; > } this issue would no longer happen, which indicates that their reframe causes this issue.

(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #21) > This triggers reframe on <popupgroup> and <tooltip> due to bug 1440258. But > why that reframe causes the tabstrip to scroll is unknown. The reason is that given they're anon content, we reconstruct the parent, that again, is the <window>. So we reframe the whole chrome, and as things happen, it seems the tabstrip state gets lost.

(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #21) > This is likely the same issue as bug 1440258 That's great news! The patch there should land shortly, so we should see the fix within a day or two. Itiel - many thanks for taking the time to help us identify and reproduce this issue!

Itiel - can you check whether this is fixed in the most recent nightly?

(In reply to Bobby Holley (:bholley) from comment #24) > Itiel - can you check whether this is fixed in the most recent nightly? Yep, all 4 issues seem to be fixed now. Thank you guys!

It's a bit late to uplift this to 59, so let's let this fix ride the trains with 60.

59 is unaffected, this only happens with stylo-chrome.