Closed Bug 1393924 Opened 7 years ago Closed 7 years ago

Collect description and preview image and store it into moz_places

Categories

(Firefox :: New Tab Page, enhancement)

57 Branch
enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 57
Tracking Status
firefox57 --- fixed

People

(Reporter: ursula, Assigned: ursula)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

For Activity Stream, we need descriptions and preview images so we can display Highlights. The work has already been done to prepare moz_places with a description and previewImageURL field so all that's left to do is collect the metadata from pages as you browse. We'll take the same approach as ContentLinkHandler.jsm, but will have something like ContentMetaHandler.jsm which will listen to DOMMetaAdded events, find the best available description and preview image based on the same criteria as we used in the Test Pilot addon, and store it in PlacesDB.

I'll submit a patch for feedback so we can discuss the approach
Assignee: nobody → usarracini
Comment on attachment 8901884 [details]
Bug 1393924 - Collect description and preview image and store it into moz_places

Marco, this is the approach we were thinking for collecting preview image and description from meta tags. It's very similar to the way ContentLinkHandler.jsm collects icons through the link tag. Would you be able to give feedback on this approach? If it looks good, I'll clean the code up and write a test before asking for formal review.
Attachment #8901884 - Flags: feedback?(mak77)
I think it's worth attaching some telemetry probes on meta parsing, such as length of preview image URL and description. We could use them to help us better understand the storage impact, and tune the data expiration policy for Places accordingly.

Here is how it handles telemetry for favicons,

http://searchfox.org/mozilla-central/source/browser/modules/ContentLinkHandler.jsm#83
Comment on attachment 8901884 [details]
Bug 1393924 - Collect description and preview image and store it into moz_places

https://reviewboard.mozilla.org/r/173298/#review178806

For the picking of meta properties/names, the most common on a quick glance seems to be og:. So probably something we don't really need to tweak for the initial landing, but something to take a deeper look later as supporting more/fewer can actually affect website implementation choices.

::: browser/base/content/tabbrowser.xml:977
(Diff revision 1)
> +        <parameter name="aPreviewImage"/>
> +        <body>
> +          <![CDATA[
> +            if (aURL) {
> +              let pageInfo = {url: aURL, description: aDescription, previewImageURL: aPreviewImage}
> +              PlacesUtils.history.update(pageInfo);

Any particular reason to have this on gBrowser?

::: browser/modules/ContentMetaHandler.jsm:23
(Diff revision 1)
> +  _metaTagsObj: new Map(),
> +  // Mapping of possible meta tags that contain a description and their respective scoring
> +  _description: {
> +    rules: {
> +      "og:description": 2,
> +      "description": 1

How were these picked and the ordering? An article I happened to have open from bloomberg seems to use the same value for each of these: description, og:description, fb:status, twitter:description, sailthru.description

::: browser/modules/ContentMetaHandler.jsm:33
(Diff revision 1)
> +    rules: {
> +      "og:image:secure_url": 5,
> +      "og:image:url": 4,
> +      "og:image": 3,
> +      "twitter:image": 2,
> +      "thumbnail": 1

Similarly, I see: og:image, twitter:image, parsely-image-url

::: browser/modules/ContentMetaHandler.jsm:67
(Diff revision 1)
> +    // Stores a mapping of the best description and preview image collected so far
> +    // for a given URL
> +    if (!this._metaTagsObj.has(url)) {
> +      this._metaTagsObj.set(url, {
> +          "description": {value: null, currMaxScore: 0},
> +          "image": {value: null, currMaxScore: 0}

I suppose we already have the page title that places is already using, so this is more of a slight "optimization"… and probably for later.

These tags seem to typically not include the site's name: og:title, twitter:title, parsely-title, sailthru.title.
Blocks: 1394533
Comment on attachment 8901884 [details]
Bug 1393924 - Collect description and preview image and store it into moz_places

https://reviewboard.mozilla.org/r/173298/#review178892

::: browser/modules/ContentMetaHandler.jsm:45
(Diff revision 1)
> +  },
> +
> +  // Check if it's a meta tag we care about, and if it's score is greater than
> +  // the current max score for that tag
> +  _shouldExtractMetadata(rules, tag, entry) {
> +    return (Object.keys(rules).includes(tag) && (rules[tag] > entry.currMaxScore));

If rules was just an array with least desired in index 0 and most desired in higher index, this line could just be \`return rules.indexOf(tag) > entry.bestScore;\` where -1 not found is not better than anything (and initialize best to -1).

::: browser/modules/ContentMetaHandler.jsm:100
(Diff revision 1)
> +      // We don't care about other meta tags
> +      return;
> +    }
> +
> +    // Save description and preview image to moz_places
> +    chromeGlobal.sendAsyncMessage("Meta:SetPageInfo", {

In practical use, do we just get a bunch of "DOMMetaAdded" all at once? So potentially this sends a message on each one (when matching a desired tag)? Potentially to avoid unnecessary messages that get immediately replaced, do some next tick to allow other about-to-be-added Meta tags to be processed?
Comment on attachment 8901884 [details]
Bug 1393924 - Collect description and preview image and store it into moz_places

https://reviewboard.mozilla.org/r/173298/#review178806

> Any particular reason to have this on gBrowser?

It just follows the same pattern we do for link tags - in ContentMetaHandler.jsm we can't insert directly into PlacesUtils, so some message passing is necessary and this was the simplest way, since we already have a handler set up in browser.js

> How were these picked and the ordering? An article I happened to have open from bloomberg seems to use the same value for each of these: description, og:description, fb:status, twitter:description, sailthru.description

The ordering right now follows the same ordering that we were using in the Test Pilot addon via the metadata parser we were using there: https://github.com/mozilla/page-metadata-parser/blob/master/parser.js#L64
It doesn't need to stay in this order, we can definitely add more or change up their scores.

> Similarly, I see: og:image, twitter:image, parsely-image-url

See above; they were taken from here: https://github.com/mozilla/page-metadata-parser/blob/master/parser.js#L104

> I suppose we already have the page title that places is already using, so this is more of a slight "optimization"… and probably for later.
> 
> These tags seem to typically not include the site's name: og:title, twitter:title, parsely-title, sailthru.title.

Yeah we can also try and parse out a better title, perhaps as a follow up ;)
Comment on attachment 8901884 [details]
Bug 1393924 - Collect description and preview image and store it into moz_places

https://reviewboard.mozilla.org/r/173298/#review178892

> If rules was just an array with least desired in index 0 and most desired in higher index, this line could just be \`return rules.indexOf(tag) > entry.bestScore;\` where -1 not found is not better than anything (and initialize best to -1).

Sure, we can also do it that way. I thought having their scores explicit was maybe more clear as to what tag was more important, but a comment saying they're to be declared in the order of importance would probably also do the job

> In practical use, do we just get a bunch of "DOMMetaAdded" all at once? So potentially this sends a message on each one (when matching a desired tag)? Potentially to avoid unnecessary messages that get immediately replaced, do some next tick to allow other about-to-be-added Meta tags to be processed?

Yeah Nan and I were discussing some possibilities for optimizing the number of messages being passed. This approach was just sort of meant to be a naive way just to get some inital feedback on the patch. Even something as simple as moving the message passing to only happen after the condition of max score being surpassed might effectively save some message passing. 

Your approach about the next tick would also probably work, you mean just bounce it back with a timeout until you think you have the best tag?
Comment on attachment 8901884 [details]
Bug 1393924 - Collect description and preview image and store it into moz_places

https://reviewboard.mozilla.org/r/173298/#review180004

I think the approach is ok, nothing too complicated and it's already tested by ContentLinkHandler, as you said.

A couple things for you to evaluate with the team:
1. did you already make Talos Tp simulations? As soon as you think you may be "ready", you should check Talos, just push to Try both the base changeset and your modified one, use --rebuild-talos 6 (or more, I used to use 10). Don't compare with other trees or results may be fancy, only compare Try with Try. Your code is very likely to have an impact on Tp, you should measure it and be prepared to answer questions from perf responsibles
2. Apart from the "batching" that both Mardak and me suggested, you could also evaluate using idleDispatchToMainThread, this information is not critical, and as such waiting a few milliseconds before storing it won't hurt and will make everyone happier.

::: browser/base/content/tabbrowser.xml:977
(Diff revision 1)
> +        <parameter name="aPreviewImage"/>
> +        <body>
> +          <![CDATA[
> +            if (aURL) {
> +              let pageInfo = {url: aURL, description: aDescription, previewImageURL: aPreviewImage}
> +              PlacesUtils.history.update(pageInfo);

a .catch(Components.utils.reportError); would be nice to give some visibility to eventual errors

::: browser/modules/ContentMetaHandler.jsm:7
(Diff revision 1)
> +/* This Source Code Form is subject to the terms of the Mozilla Public
> + * License, v. 2.0. If a copy of the MPL was not distributed with this
> + * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
> +
> +"use strict";
> +var {utils: Cu} = Components;

nit: const

::: browser/modules/ContentMetaHandler.jsm:37
(Diff revision 1)
> +      "twitter:image": 2,
> +      "thumbnail": 1
> +    }
> +  },
> +  init(chromeGlobal) {
> +    chromeGlobal.addEventListener("DOMMetaAdded", (event) => {

nit: no parenthesis

::: browser/modules/ContentMetaHandler.jsm:59
(Diff revision 1)
> +    }
> +
> +    // Ignore sub-frames
> +    if (window != window.top) {
> +      return;
> +    }

nit: could be merged with the previous early return, with a unique comment for all the conditions.

::: browser/modules/ContentMetaHandler.jsm:100
(Diff revision 1)
> +      // We don't care about other meta tags
> +      return;
> +    }
> +
> +    // Save description and preview image to moz_places
> +    chromeGlobal.sendAsyncMessage("Meta:SetPageInfo", {

I agree with Mardak that this needs some sort of batching...
Off-hand it looks like you may sent Meta:SetPageInfo for each meta in the page, and that will cause an update() call for each meta.
We should try instead to do only one update() call per page, because it's en expensive write.

Even just a 50ms timeout that you cancel and restart every time you get a new meta, when you don't get anymore new meta for 50ms you send the message.
Attachment #8901884 - Flags: feedback?(mak77)
Blocks: 1396282
While I was playing around with the query for bug 1396282, I noticed I'm doing a `description NOT NULL and preview_image_url NOT NULL`

Not sure if that means we shouldn't both storing metadata if we don't have both. Could be an interesting query to detect how many pages only have one but not the other. Where my guess is there will be fewer pages with images than those with descriptions.
Comment on attachment 8901884 [details]
Bug 1393924 - Collect description and preview image and store it into moz_places

https://reviewboard.mozilla.org/r/173296/#review181494

::: browser/modules/ContentMetaHandler.jsm:66
(Diff revision 2)
> +    // for a given URL
> +    if (!this._metaTags.has(url)) {
> +      this._metaTags.set(url, {
> +          "description": {value: null, currMaxScore: -1},
> +          "image": {value: null, currMaxScore: -1},
> +          "timeout": null

Do we need to clean up `_metaTags` at some point? In the case of not seeing any descriptions or images, we potentially create an entry for every page?

::: browser/modules/ContentMetaHandler.jsm:100
(Diff revision 2)
> +      return;
> +    }
> +
> +    if (entry.timeout) {
> +      entry.timeout.cancel();
> +      entry.timeout = null;

Looks like the timer callback will reference values on the object as opposed to some locally scoped variable. So we can just extend the timer instead of `cancel`ing and creating a new one:
https://searchfox.org/mozilla-central/source/xpcom/threads/nsITimer.idl#221-228

Just set `entry.timeout.delay` to `this._timeoutDelay`

::: browser/modules/ContentMetaHandler.jsm:112
(Diff revision 2)
> +      entry.timeout = null;
> +      // Save description and preview image to moz_places
> +      chromeGlobal.sendAsyncMessage("Meta:SetPageInfo", {
> +        url,
> +        description: entry.description.value,
> +        previewImageURL: entry.image.value

The Highlights query was confirmed to only show history that have both description and image. So I believe we should conditionally create the timer only when we have both.
Comment on attachment 8901884 [details]
Bug 1393924 - Collect description and preview image and store it into moz_places

https://reviewboard.mozilla.org/r/173296/#review181506
Comment on attachment 8901884 [details]
Bug 1393924 - Collect description and preview image and store it into moz_places

https://reviewboard.mozilla.org/r/173296/#review181588

::: browser/modules/ContentMetaHandler.jsm:37
(Diff revisions 2 - 3)
>      ]
>    },
> +  _defaultMapValues: {
> +    "description": {value: null, currMaxScore: -1},
> +    "image": {value: null, currMaxScore: -1},
> +    "tmeout": null

misspelled "timeout"

::: browser/modules/ContentMetaHandler.jsm:74
(Diff revisions 2 - 3)
>      if (!name && !prop) {
>        return;
>      }
>  
>      let tag = name || prop;
> -    let entry = this._metaTags.get(url);
> +    let entry = this._metaTags.get(url) || this._defaultMapValues;

We'll want a copy of `_defaultMapValues` so either define the object inline or do `Object.assign({}, this._defaultMapValues`

This is because… see below

::: browser/modules/ContentMetaHandler.jsm:99
(Diff revisions 2 - 3)
>  
> -    if (entry.timeout) {
> -      entry.timeout.cancel();
> -      entry.timeout = null;
> +    if (!this._metaTags.has(url)) {
> +      this._metaTags.set(url, {
> +          "description": {value: entry.description.value, currMaxScore: entry.description.currMaxScore},
> +          "image": {value: entry.image.value, currMaxScore: entry.image.currMaxScore},
> +          "timeout": entry.timeout

Here we want to just `this._metaTags.set(url, entry)` so that this current "meta" callback refers to the same entry object as any future "meta" callback.

::: browser/modules/ContentMetaHandler.jsm:112
(Diff revisions 2 - 3)
> -    entry.timeout = Cc["@mozilla.org/timer;1"].createInstance(Ci.nsITimer);
> +      entry.timeout = Cc["@mozilla.org/timer;1"].createInstance(Ci.nsITimer);
> -    entry.timeout.initWithCallback(() => {
> +      entry.timeout.initWithCallback(() => {
> -      entry.timeout = null;
> +        entry.timeout = null;
> -      // Save description and preview image to moz_places
> +
> +        // Only store into moz_places if we have both a preview image AND description
> +        if (entry.description.value && entry.image.value) {

We said that we actually want to store any data we can get so that bookmarks can show something instead of nothing.

::: browser/modules/ContentMetaHandler.jsm:116
(Diff revisions 2 - 3)
> +        // Only store into moz_places if we have both a preview image AND description
> +        if (entry.description.value && entry.image.value) {
> -      chromeGlobal.sendAsyncMessage("Meta:SetPageInfo", {
> +          chromeGlobal.sendAsyncMessage("Meta:SetPageInfo", {
> -        url,
> +            url,
> -        description: entry.description.value,
> +            description: entry.description.value,
> -        previewImageURL: entry.image.value
> +            previewImageURL: entry.image.value

We want `entry` object to be shared so that when "Meta:SetPageInfo" is sent, the locally scoped `entry` will have the fields of any modified-by-future-"meta" callback.
Attachment #8901884 - Flags: review?(mak77)
Comment on attachment 8901884 [details]
Bug 1393924 - Collect description and preview image and store it into moz_places

https://reviewboard.mozilla.org/r/173298/#review182296

::: browser/base/content/test/metaTags/browser_meta_tags.js:1
(Diff revision 5)
> +/* globals gBrowser */

please add a PD license header.

::: browser/base/content/test/metaTags/browser_meta_tags.js:2
(Diff revision 5)
> +/* globals gBrowser */
> +/* This tests that with the  page meta_tags.html, ContentMetaHandler.jsm parses out

double spacing before page

::: browser/base/content/test/metaTags/browser_meta_tags.js:6
(Diff revision 5)
> +/* globals gBrowser */
> +/* This tests that with the  page meta_tags.html, ContentMetaHandler.jsm parses out
> + * the meta tags avilable and only stores the best one for description and one for
> + * preview image url. In the case of this test, the best defined meta tags are
> + * "og:description" and "og:image:url". The list of meta tags and their order of
> + * preference is found in ContentMetaHandler.jsm. Because there is debouce logic

typo: debouce

::: browser/base/content/test/metaTags/meta_tags.html:17
(Diff revision 5)
> +    <meta property="og:image:url" content="og:image:url" />
> +    <meta name="thumbnail" content="thumbnail" />
> +  </head>
> +  <body>
> +  </body>
> +</html>

You may want a follow-up bug with a test that checks your code can handle malformed meta fields, where content is not the expected information or is even missing or doubled. Because page authors *make* mistakes.

::: browser/modules/ContentMetaHandler.jsm:14
(Diff revision 5)
> +this.EXPORTED_SYMBOLS = [ "ContentMetaHandler" ];
> +  /*
> +   * This listens to DOMMetaAdded events and collects relevant metadata about the
> +   * meta tag received. Then, it sends the metadata gathered from the meta tags
> +   * and the url of the page as it's payload to be inserted into moz_places.
> +   */

nit: remove indentation and rather add a space after the export.

::: browser/modules/ContentMetaHandler.jsm:39
(Diff revision 5)
> +  },
> +  _defaultMapValues: {
> +    "description": {value: null, currMaxScore: -1},
> +    "image": {value: null, currMaxScore: -1},
> +    "timeout": null
> +  },

nit: all of _description, _previewImage and _defaultMapValues could be const outside the ContentMetaHandler, and thus hidden to the outside world.
Also _shouldExtractMetadata could just be a function at the top level with a proper javadoc.

::: browser/modules/ContentMetaHandler.jsm:47
(Diff revision 5)
> +      this.onMetaEvent(event, chromeGlobal);
> +    });
> +    // Stores a mapping of the best description and preview image collected so far
> +    // for a given URL
> +    this._metaTags = new Map();
> +    this._timeoutDelay = 50;

why is this not just a constant in the global scope?

I'd also probably increse the time a bit, I know I said 50ms, but it was honestly just an example.
Let's say we want to keep the page loading responsive, that means the first 100ms should be dedicated to that (considered instant by the user). I'd probably say to not go lower than 100ms.

::: browser/modules/ContentMetaHandler.jsm:64
(Diff revision 5)
> +    let window = metaTag.ownerGlobal;
> +
> +    // If there's no meta tag, or we're in a sub-frame, ignore this
> +    if (!metaTag || !metaTag.ownerDocument || window != window.top) {
> +      return;
> +    }

nit: I'd suggest to move this boilerplate to the event handler above, and directly pass metaTag instead of the event to this method. maybe could also be renamed to handleMetaTag?
This filtering code is just about the event, and as such it may be logically cleaner to handle it in the event handler and enter here with a metaTag

::: browser/modules/ContentMetaHandler.jsm:88
(Diff revision 5)
> +      }
> +    } else if (this._shouldExtractMetadata(this._previewImage.rules, tag, entry.image)) {
> +      // Extract the preview image
> +      const value = metaTag.getAttributeNS(null, "content");
> +      if (value) {
> +        entry.image.value = new URL(value, url).href;

This can throw, if value is an invalid url. Off-hand it looks the code will handle that fine (the event handler with swallow the exception), so this is just a heads-up.
Attachment #8901884 - Flags: review?(mak77) → review+
Comment on attachment 8901884 [details]
Bug 1393924 - Collect description and preview image and store it into moz_places

https://reviewboard.mozilla.org/r/173298/#review182314

::: browser/base/content/test/metaTags/meta_tags.html:13
(Diff revision 5)
> +    <meta name="description" content="description" />
> +    <meta name="unknown:tag" content="unknown:tag" />
> +    <meta property="og:image" content="og:image" />
> +    <meta property="twitter:image" content="twitter:image" />
> +    <meta property="og:image:url" content="og:image:url" />
> +    <meta name="thumbnail" content="thumbnail" />

This is pretty clever test with content matching the name/property to make sure highest ranked meta is selected. Also turns out "og:image:url" is a valid URL. ;) (Although `new URL("thumbnail")` throws.)
now that I think about it, we still have the Places expiration story to figure out, we likely want to bump up the db size limit by some amount, I think Nan had filed a bug about that? it is probably a blocker.
Comment on attachment 8901884 [details]
Bug 1393924 - Collect description and preview image and store it into moz_places

https://reviewboard.mozilla.org/r/173298/#review182296

> You may want a follow-up bug with a test that checks your code can handle malformed meta fields, where content is not the expected information or is even missing or doubled. Because page authors *make* mistakes.

Sounds good
Blocks: 1397789
Blocks: 1397800
Pushed by usarracini@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/60cb967ca47f
Collect description and preview image and store it into moz_places r=mak
(In reply to Marco Bonardo [::mak] from comment #18)
> ::: browser/base/content/test/metaTags/browser_meta_tags.js:1
> (Diff revision 5)
> > +/* globals gBrowser */
> please add a PD license header.
I believe mak's "PD" is referring to "Public Domain" but you added MPL. (Although a quick grep shows a big mix of PD and MPL for tests.)
Ah, sorry about that. We can add that in a comment in bug 1397800 to change it to public domain since it'll likely be adding tests to that file/directory
Comment on attachment 8901884 [details]
Bug 1393924 - Collect description and preview image and store it into moz_places

https://reviewboard.mozilla.org/r/173298/#review182472

::: browser/modules/ContentMetaHandler.jsm:10
(Diff revision 6)
> +"use strict";
> +const {utils: Cu, interfaces: Ci, classes: Cc} = Components;
> +Cu.importGlobalProperties(["URL"]);
> +
> +// Debounce time in milliseconds
> +const TIMEOUT_DELAY = 100;

From initial testing from autoland, 100ms is not enough for many pages.

::: browser/modules/ContentMetaHandler.jsm:30
(Diff revision 6)
> +  "og:image:secure_url"
> +];
> +
> +const DEFAULT_MAP_VALUES = {
> +  "description": {value: null, currMaxScore: -1},
> +  "image": {value: null, currMaxScore: -1},

These sub-objects will be shared across all entries even when doing `Object.assign`. Oops! We can instead make this object flat:
```js
{
  description: null,
  descriptionScore: -1,
  image: null,
  imageScore: -1,
  timeout: null
}
```
(In reply to Ed Lee :Mardak from comment #27)
> These sub-objects will be shared across all entries even when doing
> `Object.assign`. Oops! We can instead make this object flat:
Alternatively, just have the object creation (with sub objects) directly in `handleMetaTag` and it'll be a fresh object. No need to fix up existing references to `entry.image.value`, etc.
As Ed mentioned, we might be able to just increase the 100ms to let the page have more time to get the metadata and that might fix the test failure in this case. I've pushed another patch that bumps it up, hopefully it does the trick
Flags: needinfo?(usarracini)
Comment on attachment 8901884 [details]
Bug 1393924 - Collect description and preview image and store it into moz_places

https://reviewboard.mozilla.org/r/173298/#review182494

Looks like this should fix things. Some nits to clean up / clarify comments.

::: browser/modules/ContentMetaHandler.jsm:10
(Diff revisions 6 - 7)
>  "use strict";
>  const {utils: Cu, interfaces: Ci, classes: Cc} = Components;
>  Cu.importGlobalProperties(["URL"]);
>  
>  // Debounce time in milliseconds
> -const TIMEOUT_DELAY = 100;
> +const TIMEOUT_DELAY = 1000;

Add to the comment that this time should be long enough to account for synchronously executed script tags that might come between meta tags within head element.

::: browser/modules/ContentMetaHandler.jsm:88
(Diff revisions 6 - 7)
> +    const DEFAULT_MAP_VALUES = {
> +      "description": {value: null, currMaxScore: -1},
> +      "image": {value: null, currMaxScore: -1},
> +      "timeout": null
> +    };
> +    let entry = this._metaTags.get(url) || DEFAULT_MAP_VALUES;

nit: just put the object directly inline so it's conditionally created. Also, you can remove the quotes around keys here.

::: browser/modules/ContentMetaHandler.jsm:88
(Diff revisions 6 - 7)
> +    const DEFAULT_MAP_VALUES = {
> +      "description": {value: null, currMaxScore: -1},
> +      "image": {value: null, currMaxScore: -1},
> +      "timeout": null
> +    };
> +    let entry = this._metaTags.get(url) || DEFAULT_MAP_VALUES;

Also, let's make this `const entry =` just in case someone tries to reassign it and it would possibly do unexpected things for the timer callback.
Attachment #8901884 - Flags: review+
Pushed by usarracini@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1b2b3bc1d47b
Collect description and preview image and store it into moz_places r=mak,Mardak
https://hg.mozilla.org/mozilla-central/rev/1b2b3bc1d47b
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
No longer blocks: CVE-2018-5118
Depends on: CVE-2018-5118
Blocks: 1420571
See Also: → 1374382
Component: Activity Streams: Newtab → New Tab Page
You need to log in before you can comment on or make changes to this bug.