Closed Bug 1269462 Opened 4 years ago Closed 4 years ago

When all windows on OS X are closed and then a new one is created, it has broken title bar

Categories

(Firefox :: Toolbars and Customization, defect)

48 Branch
x86
macOS
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 49
Tracking Status
e10s ? ---
firefox46 --- wontfix
firefox47 - wontfix
firefox48 + verified
firefox49 --- verified

People

(Reporter: MekliCZ, Assigned: Gijs)

References

Details

(Keywords: regression)

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160502004021

Steps to reproduce:

Closed all windows and then created a new one (I tried CMD+N and clicking dock icon, problem is everywhere)


Actual results:

New window has broken title bar.


Expected results:

New window's title bar should be OK.
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86
I tried to reproduce with Nightly on Mac OS 10.11 and did not see anything abnormal.
Does this happen with a new profile?
Can you take a screenshot so that we can see what 'broken' means.
Flags: needinfo?(mvasicek)
Attached image Screenshot
I tried it with new profile and it's okay. Screenshot attached.
Flags: needinfo?(mvasicek)
(In reply to Michal Vašíček from comment #2)
> Created attachment 8748237 [details]
> Screenshot
> 
> I tried it with new profile and it's okay. Screenshot attached.

As it works with a new profile, an addon is probably the cause of your problem. So this bug is resolved ;)
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
We should, however, determine which add-on[1] is causing this, and contact the add-on author if possible.

Michal - do you think you could post your about:support data?

[1]: Or non-default pref
Flags: needinfo?(mvasicek)
I disabled all add-ons, restarted firefox, closed all windows, tried to create a new one and is has a broken title bar, so it isn't problem of add-ons.
Flags: needinfo?(mvasicek)
Okay, great, that's good to know that we can eliminate add-ons as the root cause.

Nonetheless, can you please post your about:support? That'll show me a whitelist of your changed preferences.
Status: RESOLVED → REOPENED
Flags: needinfo?(mvasicek)
Resolution: WORKSFORME → ---
{
  "application": {
    "name": "Firefox",
    "osVersion": "Darwin 15.4.0",
    "arch": "x86-64",
    "version": "48.0a2",
    "buildID": "20160503004116",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0",
    "safeMode": false,
    "updateChannel": "aurora",
    "supportURL": "https://support.mozilla.org/1/firefox/48.0a2/Darwin/cs/",
    "numTotalWindows": 1,
    "numRemoteWindows": 1,
    "remoteAutoStart": true,
    "autoStartStatus": 1
  },
  "modifiedPreferences": {
    "accessibility.typeaheadfind.flashBar": 0,
    "browser.cache.frecency_experiment": 1,
    "browser.cache.disk.smart_size.first_run": false,
    "browser.cache.disk.smart_size.use_old_max": false,
    "browser.cache.disk.capacity": 358400,
    "browser.cache.disk.filesystem_reported": 1,
    "browser.download.importedFromSqlite": true,
    "browser.link.open_newwindow.restriction": 0,
    "browser.places.smartBookmarksVersion": 8,
    "browser.sessionstore.upgradeBackup.latestBuildID": "20160503004116",
    "browser.startup.homepage_override.buildID": "20160503004116",
    "browser.startup.homepage_override.mstone": "48.0a2",
    "browser.urlbar.maxRichResults": 12,
    "dom.push.userAgentID": "5e3a85cfec134654b36e7752a502ac1a",
    "dom.apps.reset-permissions": true,
    "dom.mozApps.used": true,
    "extensions.lastAppVersion": "48.0a2",
    "font.language.group": "x-western",
    "gfx.blacklist.direct2d.failureid": "FEATURE_FAILURE_DL_BLACKLIST_g984",
    "gfx.blacklist.direct2d": 3,
    "gfx.blacklist.hardwarevideodecoding": 3,
    "gfx.blacklist.hardwarevideodecoding.failureid": "FEATURE_FAILURE_DL_BLACKLIST_g1208",
    "media.gmp-manager.buildID": "20160503004116",
    "media.benchmark.vp9.versioncheck": 1,
    "media.gmp-widevinecdm.lastUpdate": 1462012417,
    "media.gmp-gmpopenh264.version": "1.5.3",
    "media.gmp-gmpopenh264.lastUpdate": 1459615642,
    "media.benchmark.vp9.fps": 95,
    "media.gmp-gmpopenh264.abi": "x86_64-gcc3-u-i386-x86_64",
    "media.gmp-manager.lastCheck": 1462293727,
    "media.gmp-widevinecdm.abi": "x86_64-gcc3-u-i386-x86_64",
    "media.gmp-widevinecdm.version": "1.4.8.866",
    "network.cookie.prefsMigrated": true,
    "network.predictor.cleaned-up": true,
    "places.database.lastMaintenance": 1462013669,
    "places.history.expiration.transient_current_max_pages": 104858,
    "plugin.importedState": true,
    "plugin.disable_full_page_plugin_for_types": "application/pdf",
    "security.sandbox.content.tempDirSuffix": "{823c1716-275d-b445-94a7-dc1757dfee1f}",
    "services.sync.declinedEngines": "",
    "services.sync.lastPing": 1462293617,
    "services.sync.lastSync": "Tue May 03 2016 18:50:24 GMT+0200 (CEST)",
    "services.sync.numClients": 1,
    "services.sync.engine.prefs.modified": false,
    "storage.vacuum.last.places.sqlite": 1460283283,
    "storage.vacuum.last.index": 1
  },
  "lockedPreferences": {},
  "javaScript": {
    "incrementalGCEnabled": true
  },
  "accessibility": {
    "isActive": false,
    "forceDisabled": 0
  },
  "libraryVersions": {
    "NSPR": {
      "minVersion": "4.12",
      "version": "4.12"
    },
    "NSS": {
      "minVersion": "3.24 Basic ECC Beta",
      "version": "3.24 Basic ECC Beta"
    },
    "NSSUTIL": {
      "minVersion": "3.24 Beta",
      "version": "3.24 Beta"
    },
    "NSSSSL": {
      "minVersion": "3.24 Basic ECC Beta",
      "version": "3.24 Basic ECC Beta"
    },
    "NSSSMIME": {
      "minVersion": "3.24 Basic ECC Beta",
      "version": "3.24 Basic ECC Beta"
    }
  },
  "userJS": {
    "exists": false
  },
  "crashes": {
    "submitted": [],
    "pending": 0
  },
  "extensions": [
    {
      "name": "Firefox Hello",
      "version": "1.3.0",
      "isActive": true,
      "id": "loop@mozilla.org"
    },
    {
      "name": "Multi-process staged rollout",
      "version": "1.0",
      "isActive": true,
      "id": "e10srollout@mozilla.org"
    },
    {
      "name": "Pocket",
      "version": "1.0",
      "isActive": true,
      "id": "firefox@getpocket.com"
    }
  ],
  "experiments": [],
  "graphics": {
    "numTotalWindows": 1,
    "numAcceleratedWindows": 1,
    "windowLayerManagerType": "OpenGL",
    "windowLayerManagerRemote": true,
    "supportsHardwareH264": "No",
    "adapterDescription": "",
    "adapterVendorID": "0x8086",
    "adapterDeviceID": "0x162b",
    "adapterRAM": "",
    "adapterDrivers": "",
    "driverVersion": "",
    "driverDate": "",
    "webglRenderer": "Intel Inc. -- Intel(R) Iris(TM) Graphics 6100",
    "info": {
      "AzureCanvasBackend": "skia",
      "AzureCanvasAccelerated": 1,
      "AzureFallbackCanvasBackend": "none",
      "AzureContentBackend": "skia",
      "ApzWheelInput": 1
    }
  }
}
Flags: needinfo?(mvasicek)
Hm, no help there, I'm afraid.

I can't reproduce at least on OS X 10.10.5. Going to see if QA can reproduce on 10.11.

Hey RyanVM - have I done the right thing with the qawanted flag here, or is there something else I need to do to have Softvision look at this?
Flags: needinfo?(ryanvm)
Keywords: qawanted
qawanted should suffice. Also, I assume this is something that used to work OK, Michal?
Flags: needinfo?(ryanvm) → needinfo?(mvasicek)
OK
Flags: needinfo?(mvasicek)
This worked on DevEdition 47 I meant?
Oh, sorry. Well, I didn't try it on DE 47.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160509004024

I can reproduce the issue on Firefox Developer Edition 48.0a2 when using the following STR:

1. Launch Aurora with a new profile
2. Pin the 2 tabs
3. Close Aurora by clicking on the "x" button located on the upper left side of the window
4. In the Dock bar, click on the Aurora icon to open a new window

Expected results:
A new window should be properly opened.

Actual results:
The title bar of the new opened window is broken. The window is also shrunk (logged Bug 1271607 to cover that issue).

Note:
The title bar is also broken on the latest Nightly 49.0a1.
The title bar is also broken on Firefox 47 beta 3 (if I pin the tabs starting with the ones from the far right to the left).
I could not reproduce the issue on the latest Firefox 46.0.1.

Removing the qawanted keyword. Please let me know if anything else is needed.
Keywords: qawanted
Component: Untriaged → Widget: Cocoa
Product: Firefox → Core
Component: Widget: Cocoa → Toolbars and Customization
Keywords: regression
Product: Core → Firefox
Flags: needinfo?(gijskruitbosch+bugs)
I can't reproduce this on Nightly, nor can I reproduce it if I build Aurora locally...

When I reproduce it on a local devedition build, it seems the cause is that the margin-bottom is not set on the titlebar at all. That leads me to believe that the TabsInTitlebar code is not running at all.

I don't know what would have caused it not to run in certain circumstances, and without the ability to reproduce on a local builds that's hard to debug...

I'm looking at mozregression now with --repo mozilla-aurora, and that seems to work.

However, I reproduced on an aurora 45 build as well. If it's aurora-specific then that somewhat mitigates the severity, though. It's also odd that this apparently reproduces even with the default theme (per the screenshot from the reporter), so I wonder what difference devedition is making. :-\
Annnnnd then I couldn't reproduce on 48 when run through mozregression. :-\

Bizarrely, I then also couldn't reproduce on my own copy of 48 after updating it to today's build (12th of May). I then launched the build for the 11th with mozregression, and could reproduce it there. So... maybe this got fixed on 48 in the last 24 hours? Or maybe it's intermittent?

Michal and Simona, if you try today's devedition build, is it fixed for you? I'd like to make sure I'm not crazy, because that is quite the coincidence...
Flags: needinfo?(simona.marcu)
Flags: needinfo?(mvasicek)
Flags: needinfo?(gijskruitbosch+bugs)
AFAICT with mozregression, this regressed on aurora when 45 became aurora. I then checked and it seems I can reproduce with mozregression on a build from before 1265577 hit nightly (ie nightly from May 5th). So I suspect it's been fixed in that bug. Going to see if I can find out when it regressed on nightly...

:tn, any idea why bug 1265577 would fix this bug? Just race conditions, or is there something saner that would explain this?

FWIW, the tabsintitlebar code basically responds to resolution changes and resize events (and some pref / customizable UI changes that shouldn't be relevant here... I *think* that's it, but I could be wrong...).
Flags: needinfo?(tnikkel)
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=a0db720c980e3fbacf92c03566e8ffea5fdefd2d&tochange=924d421d766ad07c2e76a1a299ec3e05b7ad0b4f

is what mozregression comes up with when trying to figure out when this broke on nightly... Mike, any ideas why those csets could have broken something here?
Flags: needinfo?(mconley)
(In reply to :Gijs Kruitbosch from comment #15)
> Annnnnd then I couldn't reproduce on 48 when run through mozregression. :-\
> 
> Bizarrely, I then also couldn't reproduce on my own copy of 48 after
> updating it to today's build (12th of May). I then launched the build for
> the 11th with mozregression, and could reproduce it there. So... maybe this
> got fixed on 48 in the last 24 hours? Or maybe it's intermittent?
> 
> Michal and Simona, if you try today's devedition build, is it fixed for you?
> I'd like to make sure I'm not crazy, because that is quite the coincidence...

I can still reproduce it on the latest Aurora 48.0a2 (Build ID: 20160512004026) and and Nightly 49.0a1 (Build ID: 20160511030221) when following the STR from Comment 13.

I only reproduced this issue on Mac OS X (definitely on Mac OS X 10.10). I don't remember seeing the broken title bar on the latest Nightly 49 while on Mac OS X 10.11 (statement enforced by the fact that the issue is not visible on the screencast from Bug 1271607). I can check later if the issue is also reproducible on Mac OS X 10.11 on the latest Nightly and come back with a comment. 

Please note that I can't reproduce the issue when I disable e10s.
tracking-e10s: --- → ?
Flags: needinfo?(simona.marcu)
(In reply to Simona B [:simonab] from comment #19)
> I only reproduced this issue on Mac OS X (definitely on Mac OS X 10.10). I
> don't remember seeing the broken title bar on the latest Nightly 49 while on
> Mac OS X 10.11 (statement enforced by the fact that the issue is not visible
> on the screencast from Bug 1271607).

I'm on 10.11. I tried again but still can't reproduce on today's devedition. I'll see if I can use my old mbp which IIRC was still running 10.10 to try again.

> I can check later if the issue is also
> reproducible on Mac OS X 10.11 on the latest Nightly and come back with a
> comment.

I mean, if it didn't reproduce for the screencast in bug 1271607, then I guess it doesn't happen on 10.11 for either of us? But the reporter is on 10.11 as well...

Removing ni for :tn for now because it doesn't look like this is really fixed by that bug. :-\
Flags: needinfo?(tnikkel)
(In reply to :Gijs Kruitbosch from comment #18)
> https://hg.mozilla.org/integration/fx-team/
> pushloghtml?fromchange=a0db720c980e3fbacf92c03566e8ffea5fdefd2d&tochange=924d
> 421d766ad07c2e76a1a299ec3e05b7ad0b4f
> 
> is what mozregression comes up with when trying to figure out when this
> broke on nightly... Mike, any ideas why those csets could have broken
> something here?

I... I have no idea. :/ That's truly bizarre.

Something strange must be happening within http://searchfox.org/mozilla-central/source/browser/base/content/browser-tabsintitlebar.js...

Is there nothing in the Browser Console from that region of the code?
Flags: needinfo?(mconley)
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #21)
> Something strange must be happening within
> http://searchfox.org/mozilla-central/source/browser/base/content/browser-
> tabsintitlebar.js...
> 
> Is there nothing in the Browser Console from that region of the code?

No. As far as I can tell the tabsintitlebar code doesn't fire. So whatever normally triggers that code isn't running, and that's causing the broken appearance.
Not even the init is firing? Or allowedBy? That's really quite odd... or do you just mean the updateAppearance method?
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #23)
> Not even the init is firing? Or allowedBy? That's really quite odd... or do
> you just mean the updateAppearance method?

Well, there's no easy way to verify this if I can't reproduce it on a local build. But the <titlebar> ends up with no style attribute with margin-bottom set in it, which is why the result looks so terrible... AFAICT the only way that can happen is if _update is never called. Also, when I did reproduce it on older builds, the problem went away as soon as I resized the window by even 1 pixel.
Assignee: nobody → gijskruitbosch+bugs
Status: REOPENED → ASSIGNED
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(mvasicek)
(In reply to :Gijs Kruitbosch from comment #25)
> Created attachment 8752280 [details]
> MozReview Request: Bug 1269462 - fix race condition in TabsInTitlebar code
> where it was possible we'd only be called before init(), resulting in never
> updating the titlebar maths, r?mconley,MattN
> 
> Review commit: https://reviewboard.mozilla.org/r/52515/diff/#index_header
> See other reviews: https://reviewboard.mozilla.org/r/52515/

So I eventually reproduced by updating to an older aurora rev and building from there, with official devedition branding. The patch is actually generated against that tree, now that I think about it, but this file hasn't changed very much so we should be OK.

The gist of it is that the stack into _update looks like this:

TabsInTitlebar._update@chrome://browser/content/browser-tabsintitlebar.js:102:88
updateAppearance@chrome://browser/content/browser-tabsintitlebar.js:60:5
handleEvent@chrome://browser/content/tabbrowser.xml:5354:15
updateBrowserRemoteness@chrome://browser/content/tabbrowser.xml:1595:13
updateBrowserRemotenessByURL@chrome://browser/content/tabbrowser.xml:1671:22
SessionStoreInternal.restoreTabContent@resource:///modules/sessionstore/SessionStore.jsm:3322:30
ssi_restoreNextTab@resource:///modules/sessionstore/SessionStore.jsm:3392:7
restoreTab@resource:///modules/sessionstore/SessionStore.jsm:3282:7
restoreTabs@resource:///modules/sessionstore/SessionStore.jsm:3150:7
ssi_restoreWindow@resource:///modules/sessionstore/SessionStore.jsm:3014:7
initializeWindow@resource:///modules/sessionstore/SessionStore.jsm:1112:11
SessionStoreInternal.onBeforeBrowserWindowShown@resource:///modules/sessionstore/SessionStore.jsm:1137:7
ssi_observe@resource:///modules/sessionstore/SessionStore.jsm:636:9
gBrowserInit.onLoad@chrome://browser/content/browser.js:971:5
onload@chrome://browser/content/browser.xul:1:1

And this happens before TabsInTitlebar.init() has finished (checked by logging timestamps), after which nothing else requests an update().

The patch forces an update in this case. I don't know what the performance implications of doing this are, but it seems like whatever happens, at least on OS X, the <vbox id="titlebar"> will always need a negative margin-bottom, and it doesn't start with one, so we should run this code to avoid it looking bad. :-\

Matt and Mike, does this make sense? I remember this code being pretty fragile, so I'm a little bit worried about touching it, but it feels like we have little choice. I expect that this used to do OK before e10s, and now session restore and browser loads work differently and it no longer does (when e10s is on).
Comment on attachment 8752280 [details]
MozReview Request: Bug 1269462 - fix race condition in TabsInTitlebar code where it was possible we'd only be called before init(), resulting in never updating the titlebar maths, r=mconley,MattN

https://reviewboard.mozilla.org/r/52515/#review49487

Thanks for tracking this one down!

::: browser/base/content/browser-tabsintitlebar.js:145
(Diff revision 1)
>      for (let something in this._disallowed) {
>        allowed = false;
>        break;
>      }
>  
> +

Drop the extra newline.
Attachment #8752280 - Flags: review?(mconley) → review+
Hey mcote - this might be the thing you've been seeing periodically, but have never been able to reproduce reliably. It looks like we've sorted out this race.
Comment on attachment 8752280 [details]
MozReview Request: Bug 1269462 - fix race condition in TabsInTitlebar code where it was possible we'd only be called before init(), resulting in never updating the titlebar maths, r=mconley,MattN

https://reviewboard.mozilla.org/r/52515/#review49511

LGTM.
Attachment #8752280 - Flags: review?(MattN+bmo) → review+
Comment on attachment 8752280 [details]
MozReview Request: Bug 1269462 - fix race condition in TabsInTitlebar code where it was possible we'd only be called before init(), resulting in never updating the titlebar maths, r=mconley,MattN

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/52515/diff/1-2/
Attachment #8752280 - Attachment description: MozReview Request: Bug 1269462 - fix race condition in TabsInTitlebar code where it was possible we'd only be called before init(), resulting in never updating the titlebar maths, r?mconley,MattN → MozReview Request: Bug 1269462 - fix race condition in TabsInTitlebar code where it was possible we'd only be called before init(), resulting in never updating the titlebar maths, r=mconley,MattN
https://hg.mozilla.org/mozilla-central/rev/b1b49f499ae6
Status: ASSIGNED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 49
[Tracking Requested - why for this release]:
Want to make sure we get this in for 47, but I'd like at least some baking on a weekday nightly before uplifting this and assuming nothing regressed. Matt, did mozscreenshots notice anything? I tried to use https://screenshots.mattn.ca/compare/ and it seems I broke it? :-\
Flags: needinfo?(MattN+bmo)
Just installed the latest m-c hourly/tinderbox build cset:
https://hg.mozilla.org/mozilla-central/rev/d0be57e84807ce0853b2406de7ff6abb195ac898

Now on my Win10 system the tabs are no longer in the title-bar.  Did this bug break 'tabs-in'title-bar' on Windows ?
(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #34)
> Just installed the latest m-c hourly/tinderbox build cset:
> https://hg.mozilla.org/mozilla-central/rev/
> d0be57e84807ce0853b2406de7ff6abb195ac898
> 
> Now on my Win10 system the tabs are no longer in the title-bar.  Did this
> bug break 'tabs-in'title-bar' on Windows ?

It's possible... you haven't given any details though. A screenshot would be a start. Other questions: can you reproduce on a clean profile, or not? In a maximized or a restored/"normal" window? Does resizing the window or maximizing/restoring it fix this? Is e10s on or off? A screenshot would be helpful. I just tried on Windows 8, and it seems to work fine there. It'd be surprising if there was a significant difference with Windows 10...

Please file a new bug with more details.
Flags: needinfo?(jmjeffery)
(In reply to :Gijs Kruitbosch from comment #35)
> (In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #34)
> > Just installed the latest m-c hourly/tinderbox build cset:
> > https://hg.mozilla.org/mozilla-central/rev/
> > d0be57e84807ce0853b2406de7ff6abb195ac898
> > 
> > Now on my Win10 system the tabs are no longer in the title-bar.  Did this
> > bug break 'tabs-in'title-bar' on Windows ?
> 
> It's possible... you haven't given any details though. A screenshot would be
> a start. Other questions: can you reproduce on a clean profile, or not? In a
> maximized or a restored/"normal" window? Does resizing the window or
> maximizing/restoring it fix this? Is e10s on or off? A screenshot would be
> helpful. I just tried on Windows 8, and it seems to work fine there. It'd be
> surprising if there was a significant difference with Windows 10...
> 
> Please file a new bug with more details.

(also, is this by any chance a multiple-screen/multiple-dpi machine?)
(In reply to :Gijs Kruitbosch from comment #36)
> (In reply to :Gijs Kruitbosch from comment #35)
> > (In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #34)
> > > Just installed the latest m-c hourly/tinderbox build cset:
> > > https://hg.mozilla.org/mozilla-central/rev/
> > > d0be57e84807ce0853b2406de7ff6abb195ac898
> > > 
> > > Now on my Win10 system the tabs are no longer in the title-bar.  Did this
> > > bug break 'tabs-in'title-bar' on Windows ?
> > 
> > It's possible... you haven't given any details though. A screenshot would be
> > a start. Other questions: can you reproduce on a clean profile, or not? In a
> > maximized or a restored/"normal" window? Does resizing the window or
> > maximizing/restoring it fix this? Is e10s on or off? A screenshot would be
> > helpful. I just tried on Windows 8, and it seems to work fine there. It'd be
> > surprising if there was a significant difference with Windows 10...
> > 
> > Please file a new bug with more details.
> 
> (also, is this by any chance a multiple-screen/multiple-dpi machine?)

Filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1273094
Flags: needinfo?(jmjeffery)
Duplicate of this bug: 1273179
(In reply to :Gijs Kruitbosch from comment #33)
> [Tracking Requested - why for this release]:
> Want to make sure we get this in for 47, but I'd like at least some baking
> on a weekday nightly before uplifting this and assuming nothing regressed.
> Matt, did mozscreenshots notice anything? I tried to use
> https://screenshots.mattn.ca/compare/ and it seems I broke it? :-\

Sorry, I did some server maintenance so it may not have been working when you tested. It's working now: https://screenshots.mattn.ca/compare/?oldProject=mozilla-central&oldRev=4a8ed77f6bb573f20980056bf8c1dadd125c1a85&newProject=mozilla-central&newRev=d0be57e84807ce0853b2406de7ff6abb195ac898
Flags: needinfo?(MattN+bmo)
And there were no relevant changes except I didn't look through the known inconsistencies which normally have issues with desktop icons.
(In reply to Matthew N. [:MattN] (behind on reviews) from comment #40)
> And there were no relevant changes except I didn't look through the known
> inconsistencies which normally have issues with desktop icons.

Hm,

https://screenshots.mattn.ca/compare/?oldProject=mozilla-central&oldRev=4a8ed77f6bb573f20980056bf8c1dadd125c1a85&newProject=mozilla-central&newRev=d0be57e84807ce0853b2406de7ff6abb195ac898

shows an issue with the fog in the titlebar on Windows 7 which could potentially be related, maybe? Or is that another known issue?
Flags: needinfo?(MattN+bmo)
If you're talking about the 536 pixels ones they are because a desktop icon can be seen through the Aero Glass fog and that's a known inconsistency just not flagged as such.
Flags: needinfo?(MattN+bmo)
(In reply to Matthew N. [:MattN] (behind on reviews) from comment #42)
> and that's a known inconsistency just not flagged as such.

If you refresh it will be flagged as a known inconsistency now.
Hello Gijs, should we consider uplifting this to Beta47 and/or Aurora48? Thanks!
Flags: needinfo?(gijskruitbosch+bugs)
This seems to be an e10s only issue. As Fx47 will ship with e10s off, this is now a wontfix. Please let me know if this also affects non-e10s users.
Comment on attachment 8752280 [details]
MozReview Request: Bug 1269462 - fix race condition in TabsInTitlebar code where it was possible we'd only be called before init(), resulting in never updating the titlebar maths, r=mconley,MattN

Approval Request Comment
[Feature/regressing bug #]: n/a
[User impact if declined]: broken title bar under some conditions
[Describe test coverage new/current, TreeHerder]: nope...
[Risks and why]: low risk, minor changes to how tabs in titlebar are determined
[String/UUID change made/needed]: no

NB: needs to uplift together with the win10 fix in the other bug.
Flags: needinfo?(gijskruitbosch+bugs)
Attachment #8752280 - Flags: approval-mozilla-aurora?
Comment on attachment 8752280 [details]
MozReview Request: Bug 1269462 - fix race condition in TabsInTitlebar code where it was possible we'd only be called before init(), resulting in never updating the titlebar maths, r=mconley,MattN

Fix a race condition, taking it
Attachment #8752280 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Flags: qe-verify+
I've reproduced the issue on Mac OSX 10.11.1 and Mac OSX 10.10.5 using Firefox 48.0a2 (buildID: 20160502004021).

Verified fixed on Mac OSX 10.11.1 and Mac OSX 10.10.5 using Firefox 48 Beta 1 (buildID: 20160606200529) and latest Aurora 49.0a2 (buildID: 20160617004051).
Status: RESOLVED → VERIFIED
Duplicate of this bug: 1288920
You need to log in before you can comment on or make changes to this bug.