Screen recording:
http://recordit.co/3j6e5Ohipr
(although this repro is here, I'm not suggesting only fixing the Fabric site but providing guidance to developers on how to ensure they don't run into the same/similar issues in their products. Best solution would be to fix it generically so it's unlikely consumers will run into the same issue).
Are you willing to submit a PR to fix? Yes if we can work out a fix.
Requested priority: Normal
Products/sites affected: Fabric Demo Site, SharePoint Pages
@leddie24 FYI
yeah, this isn't as much coachmarks as layer, and layered controls that don't dismiss on scroll.
things like dropdowns make sense to always be on top. But once you scroll the dropdown dismisses, so there isn't a situation where the thing that envoked the dropdown is hidden, but the dropdown is not.

Yeah agreed regarding dropdowns.
The use-case I'm facing is definitely tricky because I don't want the coachmark to dismiss on scroll (there is a property for that), but I also don't want it appearing in front of the header.
@benkaiser at that point we just need a way to manage z-index elevations. It's something we've discussed in the past
10, 100, 1000, 10000
But haven't gotten around to yet. it'd be a pretty large, project wide effort. For now, you should be able to adjust the z-index via the styles prop.
I see what you mean. It appears it can be fixed on the demo site by changing the z-index of the ms-layer to be lower than the header. Should I be approaching it with that way as a workaround for now? merging styles on the layer in order lower it's z-index for the coachmark?
@micahgodbolt @natalieethell I notice that there is a doNotLayer prop as part of calloutProps that can be passed to the coachmark, however this seems to not stop the coachmark from still rendering it's own layer.
Is there plans to fix this? as it would likely fix the issue if we could have the coachmark render on the same layer as the page contents and avoid needing to mess with z-indexes.
Coachmark doesn't actually use callout. It has it's own special layout logic. It also uses the "doNotLayer" prop, but it's inside of positioningContainerProps. 
That works perfectly! I wonder if it would also solve the issue on the demo site? should we consider adding:
positioningContainerProps: { doNotLayer: true }
to the example?
it does, but then you've got the next problem of malsized iframe

I see, can we just give the iframe some padding at the bottom to cater for it?
Thoughts @micahgodbolt ?
If you'd like to work up a PR I'd be happy to review. I haven't had a chance to dig in and find something that works.
@micahgodbolt PR created. Looks like we also need the scrollable property set to false on the example.
:tada:This issue was addressed in #7607, which has now been successfully released as [email protected].:tada:
Handy links: