Enable the ContentPlaceHolder patch.
From master1/Master1.Master (should work by default)
master1-hidden.css loaded - it shouldn't have been rendered. The visible="false" attribute did not correctly hide one of the 'hidden' stylesheet references.
master1-hidden.css was not loaded.
If the other files failed to load, then this is just another failure.
If the subsequent files loaded, then the visible="false" attribute correctly hid both of the 'hidden' stylesheet references.
master1.css loaded. This reference isn't inside a CPH (Content Place Holder),
and should work by default.
master1.css failed.
This reference isn't inside a CPH (Content Place Holder),
and should work by default.
master1-server.css loaded.
This is displayed by a runat="server" stylesheet reference in the root master page. This reference isn't inside a CPH (Content Place Holder),
and should work by default.
master1-server.css failed.
This should be hidden by a runat="server" stylesheet reference in the root master page.
This reference isn't inside a CPH (Content Place Holder),
and should work by default.
meta name="master1" was found in the control tree. This should always work, since we haven't hit a CPH yet.
meta name="master1" was not found in the control tree. This *should* work regardless, since we haven't hit a CPH yet.
meta name="master1-server" was found in the control tree. This should always work, since we haven't hit a CPH yet.
meta name="master1-server" was not found in the control tree. This *should* work regardless, since we haven't hit a CPH yet.
The Parent.TemplateControl.AppRelativeVirtualPath property here is ~/content/LiveTests/ContentPlaceHolder/master1/Master1.Master.
This should work because we aren't inside a CPH.
<asp:PlaceHolder runat="server">
The Parent.TemplateControl.AppRelativeVirtualPath property here is ~/content/LiveTests/ContentPlaceHolder/master1/Master1.Master.
This should work because we aren't inside a CPH, and even if we were, there is an intermediate PlaceHolder control to fix the problem.
</asp:PlaceHolder>
From master2/Master2.master
master2-hidden.css loaded - it shouldn't have been rendered. The visible="false" attribute did not correctly hide one of the 'hidden' stylesheet references.
master2-hidden.css was not loaded.
If the other files failed to load, then this is just another failure.
If the subsequent files loaded, then the visible="false" attribute correctly hid both of the 'hidden' stylesheet references.
master2.css loaded. This is inside a CPH, and isn't parsed by default. The patch should make this work, though.
master2.css failed. This is inside a CPH, and doesn't work by default.
This reference actually has to fight 2 bugs. 1) it isn't parsed, and 2) If it was parsed, the TemplateControl reference of the parent would be wrong.
The patch should fix both issues.
master2-server.css loaded. (runat="server" reference) This is inside a CPH, and isn't parsed by default. The patch should make this work, though.
master2-server.css failed. (runat="server" reference) This is inside a CPH, and doesn't work by default.
This reference actually has to fight 2 bugs. 1) it isn't parsed, and 2) If it was parsed, the TemplateControl reference of the parent would be wrong.
The patch should fix both issues.
meta name="master2" was found in the control tree. We're inside a CPH, so the patch is needed to make this work.
meta name="master2" was not found in the control tree. We're inside a CPH, so the patch is needed to make this work.
meta name="master2-server" was found in the control tree.We're inside a CPH, so the patch is needed to make this work.
meta name="master2-server" was not found in the control tree. We're inside a CPH, so the patch is needed to make this work.
The Parent.TemplateControl.AppRelativeVirtualPath property here is ~/content/LiveTests/ContentPlaceHolder/master1/Master1.Master.
Unless the framework has been fixed, this should be pointing the the previous template control. You can use
GetAdjustedParentTemplateControl(Parent) instead of Parent.TemplateControl to avoid this problem.
<asp:PlaceHolder runat="server">
The Parent.TemplateControl.AppRelativeVirtualPath property here is ~/content/LiveTests/ContentPlaceHolder/master2/Master2.Master.
This should be always work, since the intermedate asp:PlaceHolder control will have cached it's TemplateControl property from before the insertion of the master page controls.
</asp:PlaceHolder>
The GetAdjustedParentTemplateControl(Parent).AppRelativeVirtualPath
property here is ~/content/LiveTests/ContentPlaceHolder/master2/Master2.Master.
From page/page1.aspx (should 'pretend' to work if the url is page1/page.master, since no path resolution is needed).
page1-hidden.css loaded - it shouldn't have been rendered. The visible="false" attribute did not correctly hide one of the 'hidden' stylesheet references.
page1-hidden.css was not loaded.
If the other files failed to load, then this is just another failure.
If the subsequent files loaded, then the visible="false" attribute correctly hid both of the 'hidden' stylesheet references.
page1.css loaded. This is inside a CPH, and isn't parsed by default. The patch should make this work, though.
If page/page1.aspx is accessed directly instead of through Test.aspx, then this will 'pretend' to work, simply
because the browser can find the file anyway.
page1.css failed. This is inside a CPH, and doesn't work by default.
This reference actually has to fight 2 bugs. 1) it isn't parsed, and 2) If it was parsed, the TemplateControl reference of the parent would be wrong.
The patch should fix both issues.
page1-server.css loaded. (runat="server" reference) This is inside a CPH, and isn't parsed by default. The patch should make this work, though.
If page/page1.aspx is accessed directly instead of through Test.aspx, then this will 'pretend' to work, simply
because the browser can find the file anyway. Since the tag has runat="server" specified, it will be parsed into an HtmlGenericControl, but rendered back out
without any path rebasing.
page1-server.css failed. (runat="server" reference) This is inside a CPH, and doesn't work by default.
This reference actually has to fight 2 bugs. 1) it isn't parsed, and 2) If it was parsed, the TemplateControl reference of the parent would be wrong.
The patch should fix both issues.
meta name="page1" was found in the control tree. We're inside a CPH, so the patch is needed to make this work.
meta name="page1" was not found in the control tree. We're inside a CPH, so the patch is needed to make this work.
meta name="page1-server" was found in the control tree.We're inside a CPH, so the patch is needed to make this work.
meta name="page1-server" was not found in the control tree. We're inside a CPH, so the patch is needed to make this work.
The Parent.TemplateControl.AppRelativeVirtualPath property here is ~/content/LiveTests/ContentPlaceHolder/master2/Master2.Master.
Unless the framework has been fixed, this should be pointing the the previous template control. You can use
GetAdjustedParentTemplateControl(Parent) instead of Parent.TemplateControl to avoid this problem.
<asp:PlaceHolder runat="server">
The Parent.TemplateControl.AppRelativeVirtualPath property here is ~/content/LiveTests/ContentPlaceHolder/page/page1.aspx.
This should be always work, since the intermedate asp:PlaceHolder control will have cached it's TemplateControl property from before the insertion of the master page controls.
</asp:PlaceHolder>
The GetAdjustedParentTemplateControl(Parent).AppRelativeVirtualPath
property here is ~/content/LiveTests/ContentPlaceHolder/page/page1.aspx.