https://cloudup.com/cBIZsBlBlv9

With prefetching enabled UICollectionView uses a cache for pages that are loaded, but not yet displayed on screen. This is a dictionary <NSIndexPath : _UICollectionViewPrefetchItem>, stored under the _prefetchCacheItems instance variable.

_UICollectionViewPrefetchItem stores the layout attributes and reusable view (UICollectionViewCell in our case) for a specific index path. Views that are put into _prefetchCacheItems also get their visibility set to "hidden". This is however not via the default hidden property, bit via dedicated methods _isHiddenForReuse and _setHiddenForReuse: defined on UIView. hidden reflects the value of _isHiddenForReuse, but does not change it. When prefetched cells are determined to become visible, they are removed from the cache and _isHiddenForReuse is set to NO so they show up.

If the collection view layout gets invalidated (which happens for us when we show or hide the navigation bar), the prefetch cache gets cleared. During this, new layout attributes and potentially new prefetched cells might get queried from the layout / data source. Those cells might not match the previous prefetched cells (e.g., only cells in the last scrolled direction are preloaded again).

Here's where the problem appears to happen. During cache eviction, the removed cells do not get their _isHiddenForReuse value updated. It remains the same. Some of those cells then get re-added to new _UICollectionViewPrefetchItem objects, which ensures their _isHiddenForReuse is updated when the cell comes on screen. But some cells don't get "prefetched" again. There is no _UICollectionViewPrefetchItem created for them. Their _isHiddenForReuse value remains set and they remain at the same position they were before invalidating the layout. UICollectionView appears to be perfectly ok with thinking there's nothing wrong with that cell and just keeps it in position as is. It even sends out "will appear" delegate calls for it. But since the cell is hidden, we can't see anything.

I verified that manually ensuring _isHiddenForReuse is not set for every visible cell during layout passes fixes the issues. Prefetching appears to work fine after that.

It is very ugly when we have a lot of close headers

This is the intended behavior. In skeletons, all month-type pattern characters (L,M) are treated as equivalent, as are weekday-type pattern characters (E,c), etc. The code will match the desired type of field (e.g. abbreviated month) to the specific pattern character field that is appropriate for the desired combination of fields. For example in Russian, a full month should be MMMM if shown with a day-of-month number, but LLLL otherwise; the coe is supposed to figure this out from the CLDR data.

There is some documentation here: https://www.unicode.org/reports/tr35/tr35-dates.html#availableFormats_appendItems and a better description here: http://cldr.unicode.org/translation/date-time-patterns#TOC-Additional-Date-Time-Formats and here: http://userguide.icu-project.org/formatparse/datetime#TOC-DateTimePatternGenerator

Thank you for your feedback. Engineering has determined that this issue behaves as intended.

We are now closing this bug report.

If you just have questions about the resolution, then please update your bug report with that information so we can respond.

I witnessed the exact problem. However, I discovered that if the source Mac is HFS+ formatted, it works. When the Source Mac is APFS, it errors on the command, "asr imagescan"

Preparing image for restore + /usr/sbin/asr imagescan --source /Volumes/4TB/Library/NetBoot/NetBootSP0/HighSierraAPFS.nbi/System.dmg Block checksum: ....10....20....30....40....50....60....70....80....90....100asr: image scan failed - internal error. + mnrfiErrExit + '[' VERBOSE '!=' DEBUG ']' + echo 'Execution of '''makeNetRestoreFromItem.sh''' failed. Cleaning up.' Execution of 'makeNetRestoreFromItem.sh' failed. Cleaning up. + /bin/rm /Volumes/4TB/Library/NetBoot/NetBootSP0/HighSierraAPFS.nbi/System.dmg + exit 1 + afvErrExit + '[' VERBOSE '!=' DEBUG ']' + echo 'Execution of '''asrFromVolume.sh''' failed. Cleaning up.' Execution of 'asrFromVolume.sh' failed. Cleaning up. + '[' NO == YES ']' + exit 1 ++ exit 1

DUP of #38877494. No further information given by Apple.

Interested to know if there was ever a resolution to this issue. I've had some trouble with a disk recently and got this error, even though Disk Utility and other tools said that the volume was fine. I'm still running El Capitan (10.11.6)

Anyway ... I was able to fix it by resizing the partition in Paragon Hard Disk Manager. Pretty sure that the partition information had somehow become corrupt and the resize rewrote the partition table entry. Note that disk utility wouldn't let me modify the partitions, hence Hard Disk Manager.

Fixed under iOS 11.3

Example: https://imgur.com/a/SXmZp

See https://stackoverflow.com/questions/32041677/using-swift-with-an-os-x-preference-pane-plugin/49817203#49817203

Apple Developer Relations - October 18 2017, 10:35 PM

Engineering has provided the following feedback regarding this issue: We don’t have a solution for you currently. The most probable course of action is that we will end up asking you to localize you action name in Localizable.strings, not InfoPlist.strings. If you do that (and the plan does not change), then your action name will be localized once the original bug here (34197258) gets fixed. This is a dupe but we’re holding on to it and not closing it for now but we wanted you to know that it has been analyzed and we’re working on the original so that you can do something about this once the dupe gets fixed.

Apple Developer Relations - October 25 2017, 7:08 PM

Engineering has determined that your bug report is a duplicate of another issue and will be closed. The open or closed status of the original report your bug was duplicated to appears in a text box within the bug detail section of the bug reporter user interface. For security and privacy reasons, we don't provide access to the original bug yours was duped to. If you have any questions or concerns, please update your report directly at this link: https://bugreport.apple.com/.

DUPLICATE OF 33068800 OPEN

Engineering has determined that your bug report is a duplicate of another issue and will be closed. The open or closed status of the original report your bug was duplicated to appears in a text box within the bug detail section of the bug reporter user interface. For security and privacy reasons, we don't provide access to the original bug yours was duped to. If you have any questions or concerns, please update your report directly at this link: https://bugreport.apple.com/.

Yes, the app usage information is provided by a low level OS service that takes extension usage into consideration. We are now closing this bug report. If you have questions or comments about the resolution, please update your bug report with that information so we can respond.

DUPLICATE OF 33679804

Answer: Engineering has determined that your bug report is a duplicate of another issue and will be closed. The open or closed status of the original report your bug was duplicated to appears in a text box within the bug detail section of the bug reporter user interface. For security and privacy reasons, we don't provide access to the original bug yours was duped to. If you have any questions or concerns, please update your report directly at this link: https://bugreport.apple.com/.

DUPLICATE OF 28352195

Answer: Engineering has determined that your bug report is a duplicate of another issue and will be closed. The open or closed status of the original report your bug was duplicated to appears in a text box within the bug detail section of the bug reporter user interface. For security and privacy reasons, we don't provide access to the original bug yours was duped to. If you have any questions or concerns, please update your report directly at this link:https://bugreport.apple.com/.

Also confirm this behavior in Sublime Text 3 where the cursor disappears. The temporary fix was increasing the cursor size from the default (smallest) in System Preferences => Accessibility => Display. As a side effect, that "hack" breaks the crosshair showing when taking screenshots using COMMAND + Shift + 4.

I'd like to revert back to using the default (smallest) cursor size and have this issue fixed.

Marked as a duplicate of 35428752 on April 11, 2018. They said they're gonna close it but they haven't yet.

We are also noticing this happening randomly and some customers are impacted, any ETA will be useful.

This is a quick-fix:

func menuDidClose(_ menu: NSMenu) {
    if menu.title == "Help" {
        window.makeKey()
    }
}

For example, look at the crap that gets put into the email when Share via Email is used at this site: https://www.eng-tips.com/viewthread.cfm?qid=437029