When the user first navigates to a specific alternate display in the panels_page content editing ui, a cloned version of the original default display is created & cached for saving later if need be. My suspicion, however, is that we lose some data in the process related to the panes contained in the default display, as new panes that are added to the temporary display end up 'overwriting' the panes present in the original default display. I haven't yet debugged the process, but I can't imagine that they're actually usurping their pids; rather, there simply seems to be a problem with the indexing of the new vs. old panes internally within the $display object.

Once the form is submitted and the new did is generated, a number of old panes will disappear that is equal to the number of new panes that were created; furthermore, the old panes will vanish in the same order in which they were created in the original default display. Another symptom of this same problem is that the 'new' pane background header color (yellow instead of blue) shows up on the OLD panes, but NOT on the new panes; again, it does so in the same order as the panes were originally created.

Once the new display is properly submitted & saved, no more irregularities occur.

Comments

esmerel’s picture

Status: Active » Closed (won't fix)

No fixes are going to get committed to the 2.x line - this was all redone in 3 anyway, I think.