Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[1.0] Attached callback is differently resolved on chrome and ff #1699

Closed
Xaratas opened this issue May 31, 2015 · 3 comments
Closed

[1.0] Attached callback is differently resolved on chrome and ff #1699

Xaratas opened this issue May 31, 2015 · 3 comments

Comments

@Xaratas
Copy link

Xaratas commented May 31, 2015

FF 38 and Chrome 43 handle the attached callback and the resolution of the callstack differently.

In FF the parent and the childs are attached to the dom first. They are visible on breakpoints. And then the content of the attached callback is executed. Which allows to use element.offset_ values.
In Chrome however the attached callback is executed before all elements are attached. Only the first element is in the dom. So getting offset values for them is not possible.

I would like if the FF behavior would be regarded as correct.

Example:
https://xaratas.github.io/

Set a breakpoint on flowChartLink-behavior.html line 12. Paste this xml in the left box and press "Read Quest".

<?xml version="1.0" encoding="utf-8"?>
<QuestData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <NextNodeID>6</NextNodeID>
  <Nodes>
    <FlowChartNode xsi:type="QuestNode">
      <NodeID>0</NodeID>
      <Comments />
      <PackageID>1</PackageID>
      <ContainerNodeID>-1</ContainerNodeID>
      <Links>
        <FlowChartLink xsi:type="QuestLink">
          <FromNodeID>0</FromNodeID>
          <ToNodeID>1</ToNodeID>
          <PointsToGhost>false</PointsToGhost>
          <ClassExtender>
            <ExtendedProperties />
          </ClassExtender>
          <RequiredToExitObjective>false</RequiredToExitObjective>
        </FlowChartLink>
      </Links>
      <ClassExtender>
        <ExtendedProperties />
      </ClassExtender>
      <Conditionals>
        <Operator>And</Operator>
        <Components />
      </Conditionals>
      <OnEnterScripts />
      <OnExitScripts />
      <OnUpdateScripts />
      <IsTempText>false</IsTempText>
      <EndStates>

      </EndStates>
      <ExperienceType>Minor</ExperienceType>
      <ExperienceLevel>4</ExperienceLevel>
    </FlowChartNode>
    <FlowChartNode xsi:type="ObjectiveNode">
      <NodeID>1</NodeID>
      <Comments />
      <PackageID>1</PackageID>
      <ContainerNodeID>-1</ContainerNodeID>
      <Links>
      </Links>
      <ClassExtender>
        <ExtendedProperties />
      </ClassExtender>
      <Conditionals>
        <Operator>And</Operator>
        <Components />
      </Conditionals>
      <OnEnterScripts />
      <OnExitScripts />
      <OnUpdateScripts />
      <IsTempText>false</IsTempText>
      <AddendumIDs>
        <int>1</int>
        <int>2</int>
        <int>0</int>
      </AddendumIDs>
      <ExperienceWeight>2</ExperienceWeight>
    </FlowChartNode>
   </Nodes>
  <QuestType>2</QuestType>
</QuestData>

Expected behavior: A red line is drawn between the elements.
Actual behavior: On chrome the red line starts from top: 0, left: 0

@kevinpschaaf
Copy link
Member

This difference is due to the inability to polyfill the exact timing of parent/child lifecycle callbacks for native custom elements, hence the difference between Chrome and polyfilled browsers.

In 0.5, we had a fig-leaf solution called domReady, which was called async after the element became attached, which avoided seeing the timing difference between parent/child attachment. We have avoided adding this back in 1.0 because it was incomplete: if an element needs to inspect its children, it shouldn't only do that once at startup, but any time its children change, since this could happen when the user appendChild's to the element directly (or via distribution). We are working on a general event/callback that users will be able to use in either case.

In the meantime, you could put the work that relies on attachment in a this.async call in attached:

attached: function() {
   this.async(function() {
      // access parent/child
   });
}

@Xaratas
Copy link
Author

Xaratas commented Jun 3, 2015

Thanks for the hint. Works for me as expected :)

@kevinpschaaf
Copy link
Member

Tracking issue for the "distributed children changed" feature here: #1773

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants