|
After looking at the code, I agree with you that it does appear to be a timing issue. Each html resource each time it is updated builds a list of linked resources (css and images) and sets up signals to each to catch deletes and underlying file changes so that html resource inside a flowtab can tell its BV window to be reload itself automatically.
The same issue does not happen in Preview as it does not use FlowTabs at all and just peridically reloads itself.
So here is the problematic sequence of events (I think):
1. the first linked css file is deleted and its deleted signal in heard by Section1 associated html resource (see ResourceObjects/HTMLResource.cpp) which in turn emits a LinkedResourceUpdated signal.
2. the FlowTab holding the BookView receives this LinkedResourceUpdated signal and its LinkedResourceModified slot is invoked (see src/Tabs/FlowTab.cpp) which in turn clears the webkit caches and if the tab is at the front tries to reload its html.
3. reloading the html causes webkit to try to load both the first and second css files into its cache in a background thread asynchronously.
4. meanwhile the return from the slot happens and the second css file is now in the process of being deleted but it cannot if that exact same css file is still trying to be read back into the webkit cache by another thread
So somehow we need to NOT invalidate the cache in webkit and try reloading until ALL deleted resources have been removed.
Right now, we have no structure in place to do that as each resource in isolation when it is being deleted emits the signal that starts this process, never knowing if they are the last delete of many or not.
I really can not see an easy way to handle this right now. Perhaps breaking the LinkedResourceUpdated signal and creating some all changes done signal of some sort.
This may take some thinking and again it is just another reason for BV to go away.
|