Closed
      
        Bug 430050
      
      
        Opened 17 years ago
          Closed 17 years ago
      
        
    
  
xul:browser changes break Firebug
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
        RESOLVED
        FIXED
        
    
  
People
(Reporter: smaug, Assigned: smaug)
References
Details
Attachments
(3 files)
| 7.99 KB,
          patch         | sicking
:
              
              review+ jst
:
              
              superreview+ damons
:
              
              approval1.9+ | Details | Diff | Splinter Review | 
| 2.82 KB,
          patch         | Details | Diff | Splinter Review | |
| 8.03 KB,
          patch         | Details | Diff | Splinter Review | 
      No description provided.
| Assignee | ||
| Updated•17 years ago
           | 
        Attachment #316804 -
        Flags: review?(jonas)
| Comment 1•17 years ago
           | ||
Gotta block, and we need some test coverage here, clearly. :/
Flags: blocking1.9+
| Assignee | ||
| Comment 2•17 years ago
           | ||
yup, I'm writing tests.
| Assignee | ||
| Updated•17 years ago
           | 
Assignee: nobody → Olli.Pettay
|   | ||
| Comment 3•17 years ago
           | ||
I don't want to discourage your work on this problem, but it need not block 411814, firebug no longer uses loadURI in its own load sequence.
| Comment 4•17 years ago
           | ||
I would be extremely surprised if this didn't also affect other extensions, but yeah, thanks a ton for that parallel fix.
| Assignee | ||
| Comment 5•17 years ago
           | ||
This is not a perfect test. I should still figure out how to test the
behavior Firebug does. But useful test anyway.
Comment on attachment 316804 [details] [diff] [review]
cancel frameloader initialization when needed.
>+  // Don't use a temporary array for mInitializableFrameLoaders, because
>+  // loading a frame may cause some other frameloader to be removed from the
>+  // array. But be careful to keep the loader alive when starting the load!
>+  while (mInitializableFrameLoaders.Length()) {
>+    nsRefPtr<nsFrameLoader> loader = mInitializableFrameLoaders[0];
>+    mInitializableFrameLoaders.RemoveElementAt(0);
>+    if (loader) {
>+      loader->ReallyStartLoading();
Is the nullcheck really needed?
>@@ -6808,16 +6808,28 @@ nsDocShell::InternalLoad(nsIURI * aURI,
>         return NS_ERROR_FAILURE;
>     }
> 
>     rv = CheckLoadingPermissions();
>     if (NS_FAILED(rv)) {
>         return rv;
>     }
> 
>+    // If this docshell is owned by a frameloader, make sure to cancel
>+    // possible frameloader initialization before loading a new page.
>+    nsCOMPtr<nsIDocShellTreeItem> parent;
>+    GetParent(getter_AddRefs(parent));
>+    if (parent) {
>+      nsCOMPtr<nsIDOMDocument> domDoc = do_GetInterface(parent);
>+      nsCOMPtr<nsIDocument> doc = do_QueryInterface(domDoc);
Silly that docshells don't GetInterface to nsIDocument :(
r=me
        Attachment #316804 -
        Flags: review?(jonas) → review+
| Assignee | ||
| Comment 7•17 years ago
           | ||
Comment on attachment 316804 [details] [diff] [review]
cancel frameloader initialization when needed.
nullcheck is not needed.
Doesn't cause any harm though.
        Attachment #316804 -
        Flags: superreview?(jst)
| Updated•17 years ago
           | 
        Attachment #316804 -
        Flags: superreview?(jst) → superreview+
| Assignee | ||
| Updated•17 years ago
           | 
        Attachment #316804 -
        Flags: approval1.9?
| Comment 8•17 years ago
           | ||
Comment on attachment 316804 [details] [diff] [review]
cancel frameloader initialization when needed.
a1.9+=damons
        Attachment #316804 -
        Flags: approval1.9? → approval1.9+
| Assignee | ||
| Comment 9•17 years ago
           | ||
| Assignee | ||
| Updated•17 years ago
           | 
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
          You need to log in
          before you can comment on or make changes to this bug.
        
Description
•