Bug 1609631 Comment 14 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
To get an idea of which large messages we're sending when viewing a large PDF, I trimmed down the PDF from comment 1 to the first 10 pages and it ends up being 9MB. Here are the large messages we send using the FileReader.readAsDataURL() test case from comment 2.

```
  PBrowser::Msg_OnStateChange | seqno       -151 | from pid  20848 | size 25161060 (24MB)
       PBrowser::Msg_VisitURI | seqno       -154 | from pid  20848 | size 12580524 (12MB)
 Browser::Msg_NewWindowGlobal | seqno       -157 | from pid  20848 | size 12580812 (12MB)
PBrowser::Msg_NewWindowGlobal | seqno       -157 | from pid  20848 | size 12580812 (12MB)
```

For `Msg_VisitURI`, we send the URI over IPC from the child to the parent to populate the history, but in the parent we throw away the URI because it's too large to pass nsNavHistory::CanAddURI(). (It's also not a supported type in this case being a data URI.) In this example we could trim off 12MB of IPC traffic and allocations by checking the URI suitability in the child before sending it over.
Revision 1 by
on 
To get an idea of which large messages we're sending when viewing a large PDF, I trimmed down the PDF from comment 1 to the first 10 pages and it ends up being 9MB. Here are the large messages we send using the FileReader.readAsDataURL() test case from comment 2.

```
  PBrowser::Msg_OnStateChange | seqno       -151 | from pid  20848 | size 25161060 (24MB)
       PBrowser::Msg_VisitURI | seqno       -154 | from pid  20848 | size 12580524 (12MB)
 Browser::Msg_NewWindowGlobal | seqno       -157 | from pid  20848 | size 12580812 (12MB)
PBrowser::Msg_NewWindowGlobal | seqno       -157 | from pid  20848 | size 12580812 (12MB)
```

For `Msg_VisitURI`, we send the URI over IPC from the child to the parent to populate the history, but in the parent we throw away the URI because it's too large to pass nsNavHistory::CanAddURI(). (It's also not a supported type in this case being a data URI.) In this example we could trim off 12MB of IPC traffic and allocations by checking the URI suitability in the child before sending it over. We could also skip sending the URI for sessions where the history is disabled.
Revision 2 by
on 
To get an idea of which large messages we're sending, I trimmed down the PDF from comment 1 to the first 10 pages and it ends up being 9MB. Here are the large messages we send using the FileReader.readAsDataURL() test case from comment 2.

```
  PBrowser::Msg_OnStateChange | seqno       -151 | from pid  20848 | size 25161060 (24MB)
       PBrowser::Msg_VisitURI | seqno       -154 | from pid  20848 | size 12580524 (12MB)
 Browser::Msg_NewWindowGlobal | seqno       -157 | from pid  20848 | size 12580812 (12MB)
PBrowser::Msg_NewWindowGlobal | seqno       -157 | from pid  20848 | size 12580812 (12MB)
```

For `Msg_VisitURI`, we send the URI over IPC from the child to the parent to populate the history, but in the parent we throw away the URI because it's too large to pass nsNavHistory::CanAddURI(). (It's also not a supported type in this case being a data URI.) In this example we could trim off 12MB of IPC traffic and allocations by checking the URI suitability in the child before sending it over. We could also skip sending the URI for sessions where the history is disabled.

Back to Bug 1609631 Comment 14