1193387 - Import reading list from Microsoft Edge

Status: VERIFIED FIXED

(Firefox :: Migration, defect, P2)

Description

[:Gijs (he/him)]

+++ This bug was initially created as a clone of Bug #1192032 +++

We need a migrator that can import a user's existing Edge reading list.

Comment 1

[Bryan Clark (DevTools PM) [:clarkbw]]

Adding Nate as a heads up.  I'm assuming we might want to import the reading list into a bookmark folder or something initially; we'll see as we work through this bug.  However the list is saved, Pocket could offer people a way to import those items.

This item isn't a high priority so lets loop back on this later.

Comment 2

[:Gijs (he/him)]

It seems this stuff is in %LocalAppData%\Packages\Microsoft.MicrosoftEdge_8...we\AC\MicrosoftEdge\User\Default\DataStore\Data\nouser1\<somenumbers>\DBStore\spartan.edb

That looks to be an https://en.wikipedia.org/wiki/Extensible_Storage_Engine DB, which the ESENT APIs should be allowing access to. I haven't found any software that lets you easily browse an ESE database, so it looks like diving into it any further would require writing custom code.

Comment 3

[:Gijs (he/him)]

I'm working on this, but it's been very slow going.

So it really is an ESE database.

There's a ReadingList table, which has a number of columns including URL, Title and AddedDate, which are what we care about. I've figured out (thanks, Archaeopteryx) how to go from the int64 date table to something we can work with.

I have a working one-file standalone cpp-based program that reads all the entries in the DB.

The problem right now is that integrating that code into gecko is breaking the loading of browsercomps.dll, which is where the component ends up, for as-yet unknown reasons. It seems to have something to do with loading esent.dll - which is kind of essential for the whole thing to work, so that's where I'm stuck now. For a bit more detail, see http://logs.glob.uno/?c=mozilla%23developers&s=21+Aug+2015&e=21+Aug+2015#c1280879 (and further) and then http://logs.glob.uno/?c=mozilla%23developers&s=21+Aug+2015&e=21+Aug+2015#c1280996 .

I've tried bisecting my patch, and essentially as soon as the component links to anything from esent.dll, stuff breaks. Note that this code isn't executing at all - just linking to it, and loading browsercomps.dll (which then presumably loads esent.dll) breaks.

I'll go from there on Monday, though if people have ideas about what to try before then, I'm all ears.

Initial patch: https://pastebin.mozilla.org/8843442
Debugging: https://pastebin.mozilla.org/8843443

Comment 4

[Jim Mathies [:jimm]]

If you attach a release build of browsercomps.dll here, I can take a look at its imports.

Comment 5

[Jim Mathies [:jimm]]

or you can using depends - http://dependencywalker.com/

Comment 6

[:Gijs (he/him)]

Attachment: browsercomps.dll

I tried using dependencywalker yesterday. Both a working and a broken copy use lots of api-ms-win-... dlls that it can't find. Other than that I didn't find something that pinpointed what was going wrong, but I've never used dependencywalker before and found it, as Mossop said on IRC, "a bit like reading tea leaves"...

Specifically, I *think* that this version wants the following DLLs which the working version doesn't:

+API-MS-WIN-CORE-PROCESSTOPOLOGY-OBSOLETE-L1-1-0.DLL
+API-MS-WIN-CORE-REGISTRY-L2-2-0.DLL
+API-MS-WIN-CORE-VERSION-L1-1-1.DLL
+API-MS-WIN-CORE-VERSION-PRIVATE-L1-1-0.DLL
+API-MS-WIN-CORE-VERSIONANSI-L1-1-1.DLL
+API-MS-WIN-DEVICES-QUERY-L1-1-1.DLL
+API-MS-WIN-EVENTING-OBSOLETE-L1-1-0.DLL
+API-MS-WIN-EVENTLOG-LEGACY-L1-1-0.DLL
+API-MS-WIN-MM-JOYSTICK-L1-1-0.DLL
+API-MS-WIN-MM-MME-L1-1-0.DLL
+API-MS-WIN-MM-TIME-L1-1-0.DLL
+API-MS-WIN-PERF-LEGACY-L1-1-0.DLL
+API-MS-WIN-SECURITY-GROUPPOLICY-L1-1-0.DLL
+API-MS-WIN-CORE-PSAPI-OBSOLETE-L1-1-0.DLL

("+" being from a diff of the before + after list that I did)

Comment 7

[:Gijs (he/him)]

My issues here seem to be caused by the dll blocklist code, specifically this code:

https://dxr.mozilla.org/mozilla-central/rev/8a6045d14d6bd348a3b5bfeb55a9321e680cc93e/mozglue/build/WindowsDllBlocklist.cpp#473-476


  // In Windows 8, the first parameter seems to be used for more than just the
  // path name.  For example, its numerical value can be 1.  Passing a non-valid
  // pointer to SearchPathW will cause a crash, so we need to check to see if we
  // are handed a valid pointer, and otherwise just pass nullptr to SearchPathW.
  PWCHAR sanitizedFilePath = (intptr_t(filePath) < 1024) ? nullptr : filePath;

on my win10 machine, that number can be e.g. 0x00000801 .

We pass that on to SearchPathW and that causes the loading of the dll to fail. Happily we don't ourselves crash, but browsercomps.dll fails to load, anyway.

Increasing this number to 8192 (semi-randomly chosen) made things work.

I suspect the int is some kind of flag - but I don't know what would be the "correct" way to distinguish the two different types of calls - though I did notice, when stopped in windbg, that our patched loader code was on the stack twice.


The code here seems to have been introduced by bug 694432, and https://bugzilla.mozilla.org/show_bug.cgi?id=732589 seems to have run into this exact issue before...

Ehsan, Jim, bsmedberg - what would you like me to do here?

Comment 8

[Benjamin Smedberg]

->dmajor

Comment 9

[:Gijs (he/him)]

Specifically, the stack seems to be:

00 0047d918 76f70625 ntdll!RtlInitUnicodeStringEx+0x20
01 0047d968 64022043 KERNELBASE!SearchPathW+0xa5
02 0047d988 640222c5 mozglue!`anonymous namespace'::getFullPath(wchar_t * filePath = 0x00000801 "--- memory read error at address 0x00000801 ---", wchar_t * fname = 0x68b61678 "api-ms-win-core-synch-l1-1-0.dll")+0x24 [c:\dev\fx-team\mozglue\build\windowsdllblocklist.cpp @ 482]
03 0047da60 76f5a069 mozglue!`anonymous namespace'::patched_LdrLoadDll(wchar_t * filePath = 0x00000801 "--- memory read error at address 0x00000801 ---", unsigned long * flags = 0x0047da88, struct _UNICODE_STRING * moduleFileName = 0x0047da98 "api-ms-win-core-synch-l1-1-0.dll", void ** handle = 0x0047da8c)+0x240 [c:\dev\fx-team\mozglue\build\windowsdllblocklist.cpp @ 689]
04 0047daa4 68c564fc KERNELBASE!LoadLibraryExW+0x149
05 0047db74 68c41202 ESENT!JetGetColumnInfoA+0xd4c
06 0047db8c 68c4111e ESENT!JetCommitTransaction2+0x1132
07 0047db98 77525cbe ESENT!JetCommitTransaction2+0x104e
08 0047dbb8 774fb737 ntdll!WinSqmSetDWORD64+0x2e
09 0047dc08 774e7d6c ntdll!RtlActivateActivationContextUnsafeFast+0xd7
0a 0047dc88 774e7c18 ntdll!LdrShutdownProcess+0x39c
0b 0047dcac 774e7c2f ntdll!LdrShutdownProcess+0x248
0c 0047dcd4 775085e8 ntdll!LdrShutdownProcess+0x25f
0d 0047dcf0 774fffbe ntdll!RtlMapGenericMask+0x348
0e 0047dd38 7750209a ntdll!RtlImageNtHeader+0x19e
0f 0047de84 77504d05 ntdll!RtlCompareUnicodeStrings+0x29a
10 0047df08 6402244c ntdll!LdrLoadDll+0x75
11 0047dfe8 76f5a069 mozglue!`anonymous namespace'::patched_LdrLoadDll(wchar_t * filePath = 0x00000001 "--- memory read error at address 0x00000001 ---", unsigned long * flags = 0x0047e010, struct _UNICODE_STRING * moduleFileName = 0x0047e020 "C:\dev\builds\opt\dist\bin\browser\components\browsercomps.dll", void ** handle = 0x0047e014)+0x3c7 [c:\dev\fx-team\mozglue\build\windowsdllblocklist.cpp @ 702]
12 0047e02c 5e4890ba KERNELBASE!LoadLibraryExW+0x149
13 0047e06c 774f48a3 nss3!pr_LoadLibraryByPathname(char * name = 0x645c3a43 "--- memory read error at address 0x645c3a43 ---", int flags = 0n1650226789)+0x1ea [c:\dev\fx-team\nsprpub\pr\src\linking\prlink.c @ 726]
14 00000000 00000000 ntdll!RtlFreeUnicodeString+0x2b3

Comment 10

[:Gijs (he/him)]

dmajor suggested via email that I try 4096 which should be safe. That worked. I'll put up a patch for that tomorrow and then try to finish off the original work of this bug.

Comment 11

[:Gijs (he/him)]

I can't figure out how to publish this on reviewboard for this bug instead of bug 1192036, which has to be in the tree because the patch here relies on that one, and reviewboard then decides that the push is an update of my review on that bug instead of this one. smacleod, any idea what's up there? Can I override this somehow?

In any case, the patch is up at https://reviewboard-hg.mozilla.org/gecko/rev/5d6257ef2be2 , and I guess I'll just stick it in a splinter attachment.

Comment 12

[:Gijs (he/him)]

Attachment: Patch v1

Note that besides bug 1192039 you also need bug 1198186 applied for this to work on win10 (at least IME, see earlier comments).

Comment 13

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #12)
> Created attachment 8652597 [details] [diff] [review]
> Patch v1
> 
> Note that besides bug 1192039

err, sleepy me, I meant bug 1192036 - I'll stop spamming this bug now. :S

Comment 14

[Steven MacLeod [:smacleod]]

(In reply to :Gijs Kruitbosch from comment #11)
> I can't figure out how to publish this on reviewboard for this bug instead
> of bug 1192036, which has to be in the tree because the patch here relies on
> that one, and reviewboard then decides that the push is an update of my
> review on that bug instead of this one. smacleod, any idea what's up there?
> Can I override this somehow?
> 
> In any case, the patch is up at
> https://reviewboard-hg.mozilla.org/gecko/rev/5d6257ef2be2 , and I guess I'll
> just stick it in a splinter attachment.

You need to specify which commits for review when you push. For single commits though you need to use the '-c' argument. You want something like
hg push review -c 5d6257ef2be2

Comment 15

[:Gijs (he/him)]

Attachment: MozReview Request: Bug 1193387 - import reading list from MS Edge, r?jaws

Bug 1193387 - import reading list from MS Edge, r?jaws

Comment 16

[:Gijs (he/him)]

(the whitespace changes would be the result of running dos2unix on some of these files...)

Comment 17

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8652869 [details]
MozReview Request: Bug 1193387 - import reading list from MS Edge, r?jaws

https://reviewboard.mozilla.org/r/17301/#review15751

::: browser/components/migration/MSMigrationUtils.jsm:311
(Diff revision 1)
> +      } else {
> +        let getSubdirs = someDir => {
> +          let subdirs = someDir.directoryEntries;

what kind of logging/telemetry should we do here to get an idea of how often we have to fallback to brute-forcing our way of finding the readinglist directory?

::: browser/components/migration/MSMigrationUtils.jsm:339
(Diff revision 1)
> +      Cu.reportError("Failed to extract Edge reading list information from the database at " + dbPath + " due to the following error: " + ex);

nit, wrap this line please

::: browser/components/migration/MSMigrationUtils.jsm:351
(Diff revision 1)
> +      let dateAdded = time ? new Date(time / 1000) : new Date();

MDN says `new Date(value)` takes the number of milliseconds since 1970. Dividing by 1000 here either tells me that Edge is storing this data in microseconds or something is wrong.

::: browser/components/migration/nsEdgeReadingListExtractor.cpp:10
(Diff revision 1)
> +//#include "nsIConsoleService.h"

This line can be removed.

::: browser/components/migration/nsEdgeReadingListExtractor.cpp:92
(Diff revision 1)
> +  if (urlColumnInfo.cbMax > MAX_URL_LENGTH) {
> +    /*nsCOMPtr<nsIConsoleService> consoleService = do_GetService(NS_CONSOLESERVICE_CONTRACTID);
> +    if (consoleService) {
> +      consoleService->LogStringMessage(NS_LITERAL_STRING("Edge migration: URL column size increased").get());
> +    }*/
> +  }

These lines can either be removed or kept but uncommented in a way to help us diagnose why something isn't working in bug reports.

::: browser/components/migration/nsEdgeReadingListExtractor.cpp:101
(Diff revision 1)
> +  if (titleColumnInfo.cbMax > MAX_TITLE_LENGTH) {
> +    /*nsCOMPtr<nsIConsoleService> consoleService = do_GetService(NS_CONSOLESERVICE_CONTRACTID);
> +    if (consoleService) {
> +      consoleService->LogStringMessage(NS_LITERAL_STRING("Edge migration: Title column size increased").get());
> +    }*/
> +  }

Ditto.

::: browser/components/migration/nsEdgeReadingListExtractor.cpp:119
(Diff revision 1)
> +  JET_COLUMNID urlColumnId, titleColumnId, addedDateColumnId;
> +  urlColumnId = urlColumnInfo.columnid;
> +  titleColumnId = titleColumnInfo.columnid;
> +  addedDateColumnId = addedDateColumnInfo.columnid;

Please declare and define in the same line.
JET_COLUMNID urlColumnId = urlColumnInfo.columnid;
JET_COLUMNID titleColumnId = titleColumnInfo.columnid;
...

::: browser/components/migration/nsEdgeReadingListExtractor.cpp:150
(Diff revision 1)
> +    printf("Got reading list item: %S (%S)\n", titleBuffer, urlBuffer);

debug line that can be removed.

::: browser/components/migration/nsEdgeReadingListExtractor.cpp:183
(Diff revision 1)
> +nsEdgeReadingListExtractor::ConvertJETError(const JET_ERR aError)

nit, pass by const reference.

::: browser/locales/en-US/chrome/browser/migration/migration.properties:20
(Diff revision 1)
> +importedEdgeReadingList=Reading List (From Edge)

The source name for Safari is just "Safari" but the source name for Edge is "Microsoft Edge". Should this say "Reading List (from Microsoft Edge)" so it matches the source name?

Comment 18

[:Gijs (he/him)]

https://reviewboard.mozilla.org/r/17301/#review15751

> what kind of logging/telemetry should we do here to get an idea of how often we have to fallback to brute-forcing our way of finding the readinglist directory?

Not sure. We could add events, and simply count how often each gets hit?

> MDN says `new Date(value)` takes the number of milliseconds since 1970. Dividing by 1000 here either tells me that Edge is storing this data in microseconds or something is wrong.

Edge isn't storing the date in microseconds, PRTime is (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSPR/Reference/PRTime). Edge stores it in 100 nanoseconds since 1601, or something (see https://msdn.microsoft.com/en-us/library/windows/desktop/ms724284%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 ). Microsoft's docs then tell us not to rely on that, so we convert to SystemTime, and then to PRTime, using pre-existing code from the cookie importer (see nsWindowsMigrationUtils.h in this patch).

I'll add a comment.

> nit, pass by const reference.

JET_ERR is a typedef for |long|. Shouldn't that be pass by value?

> The source name for Safari is just "Safari" but the source name for Edge is "Microsoft Edge". Should this say "Reading List (from Microsoft Edge)" so it matches the source name?

I think this will be sufficiently clear, and I was worried about "From Microsoft Edge" being quite long, especially in l10n. Does that sound OK, or are you worried this is not sufficiently clear? I don't feel super strongly about it, so I can change it if you prefer.

Comment 19

[:Gijs (he/him)]

(In reply to Gijs Kruitbosch (PTO until Sep 6) from comment #18)

Comment 20

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Gijs Kruitbosch (PTO until Sep 6) from comment #18)
> https://reviewboard.mozilla.org/r/17301/#review15751
> 
> > what kind of logging/telemetry should we do here to get an idea of how often we have to fallback to brute-forcing our way of finding the readinglist directory?
> 
> Not sure. We could add events, and simply count how often each gets hit?

Can you file a follow-up bug for a keyed histogram to track errors with that the migrator hits?
 
> > The source name for Safari is just "Safari" but the source name for Edge is "Microsoft Edge". Should this say "Reading List (from Microsoft Edge)" so it matches the source name?
> 
> I think this will be sufficiently clear, and I was worried about "From
> Microsoft Edge" being quite long, especially in l10n. Does that sound OK, or
> are you worried this is not sufficiently clear? I don't feel super strongly
> about it, so I can change it if you prefer.

Ok, "Reading List (from Edge)" works for me.

Comment 21

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/ef82210d0bf3

Comment 22

[Ryan VanderMeulen [:RyanVM]]

Backed out for various WinXP test failures.
https://treeherder.mozilla.org/logviewer.html#?job_id=4438650&repo=fx-team
https://treeherder.mozilla.org/logviewer.html#?job_id=4438796&repo=fx-team
https://treeherder.mozilla.org/logviewer.html#?job_id=4438800&repo=fx-team

And others. Hopefully they all boil down to one root cause.

https://hg.mozilla.org/integration/fx-team/rev/36c11b0aaa7c

Comment 23

[:Gijs (he/him)]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #22)
> Backed out for various WinXP test failures.
> https://treeherder.mozilla.org/logviewer.html#?job_id=4438650&repo=fx-team
> https://treeherder.mozilla.org/logviewer.html#?job_id=4438796&repo=fx-team
> https://treeherder.mozilla.org/logviewer.html#?job_id=4438800&repo=fx-team

Ugh. I ran my local build on XP before pushing because I was worried about this - Jim had mentioned that this might be a problem because of the JET_VER thing. It ran fine and I could see about:home (which broke when I previously had issues here) - I don't know what's different on infra. :-\

Hopefully I just need to delayload esent.dll:

remote:   https://treeherder.mozilla.org/#/jobs?repo=try&revision=6335fe47b296

Comment 24

[:Gijs (he/him)]

Try is green! Setting checkin-needed for the trypushed version of the patch.

Comment 25

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/f72069ed655c

Comment 26

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/f72069ed655c

Comment 27

[:Gijs (he/him)]

Attachment: Patch for Aurora

This patch includes:
- prerequisite bug 1198186
- this bug's patch (de-conflicted)
- followup bug 1200656 and bug 1200187 to ensure this doesn't leak and builds on msvc2015 (which may or may not work for other reasons on aurora, I'm not sure - but even if not it'll help to avoid conflicts in any other uplifts we may or may not end up doing for 42.

Unfortunately, there is 1 additional string in this patch. There are a number of options.
a. hardcode "Reading List (From Edge)".
b. land on aurora anyway and ask people to translate the string.
c. use the same name as we use for the "normal" bookmarks ("From Microsoft Edge"). Places is fine with two folders with identical names, though it would be confusing for the user.
d. use just the browser name (without "from") so at least there's a distinction. I couldn't find other (more clear) strings that we can use here. :-(

e. don't land the feature at all for 42.


Philipp/dolske, can you give feedback about what to do here?

Comment 28

[Carsten Book [:Tomcat]]

(In reply to Gijs Kruitbosch (gone until Tue 22 Sep) from comment #27)

> e. don't land the feature at all for 42.
> 
> 
> Philipp/dolske, can you give feedback about what to do here?

also note with merge day today aurora is now beta, so this would need then beta approval

Comment 29

[:Gijs (he/him)]

Talked with dolske, going to uplift with the normal bookmarks string ("From Microsoft Edge"), need to update the patch for that.

Comment 30

[:Gijs (he/him)]

Attachment: Patch for beta

Comment 31

[:Gijs (he/him)]

Comment on attachment 8667274 [details] [diff] [review]
Patch for beta

Approval Request Comment
[Feature/regressing bug #]: import reading list from MS Edge
[User impact if declined]: no reading list import
[Describe test coverage new/current, TreeHerder]: minimal test coverage on win10 (which we don't have on treeherder yet)
[Risks and why]: low risk - will only affect win10 edge imports
[String/UUID change made/needed]: nope, see earlier comments

Comment 32

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8667274 [details] [diff] [review]
Patch for beta

Patch too big, new feature (yeh, I know, this can be discussed), no test, I guess this can ride the train from 43, don't you think?

Comment 33

[:Gijs (he/him)]

Attachment: diff-without-whitespace.txt

Sylvestre said a diff -w might change his mind. :-)

Comment 34

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8669650 [details] [diff] [review]
diff-without-whitespace.txt


OK, with the -w, it is more reasonable.
Most of the diff is in new files/methods, mitigating the risk of regressions, taking it. Should be in 42 beta 4.

Comment 35

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8669650 [details] [diff] [review]
diff-without-whitespace.txt

already in 43.

Comment 36

[Carsten Book [:Tomcat]]

this failed to apply:

renamed 1193387 -> diff-without-whitespace.txt
applying diff-without-whitespace.txt
patching file browser/components/build/moz.build
Hunk #1 FAILED at 16
1 out of 1 hunks FAILED -- saving rejects to file browser/components/build/moz.build.rej
patching file browser/components/build/nsBrowserCompsCID.h
Hunk #1 FAILED at 2
1 out of 1 hunks FAILED -- saving rejects to file browser/components/build/nsBrowserCompsCID.h.rej
patching file browser/components/build/nsModule.cpp
Hunk #1 FAILED at 10
Hunk #2 FAILED at 34
Hunk #3 FAILED at 111
3 out of 3 hunks FAILED -- saving rejects to file browser/components/build/nsModule.cpp.rej
patching file browser/components/migration/IEProfileMigrator.js
Hunk #1 FAILED at 76
1 out of 1 hunks FAILED -- saving rejects to file browser/components/migration/IEProfileMigrator.js.rej
patching file browser/components/migration/MSMigrationUtils.jsm
Hunk #1 FAILED at 15
Hunk #2 FAILED at 218
Hunk #3 FAILED at 279
3 out of 3 hunks FAILED -- saving rejects to file browser/components/migration/MSMigrationUtils.jsm.rej
patching file browser/components/migration/moz.build
Hunk #1 FAILED at 2
1 out of 1 hunks FAILED -- saving rejects to file browser/components/migration/moz.build.rej
file browser/components/migration/nsEdgeReadingListExtractor.cpp already exists
1 out of 1 hunks FAILED -- saving rejects to file browser/components/migration/nsEdgeReadingListExtractor.cpp.rej
file browser/components/migration/nsEdgeReadingListExtractor.h already exists
1 out of 1 hunks FAILED -- saving rejects to file browser/components/migration/nsEdgeReadingListExtractor.h.rej
patching file browser/components/migration/nsIEHistoryEnumerator.cpp
Hunk #1 FAILED at 0
Hunk #2 FAILED at 98
2 out of 2 hunks FAILED -- saving rejects to file browser/components/migration/nsIEHistoryEnumerator.cpp.rej
file browser/components/migration/nsIEdgeReadingListExtractor.idl already exists
1 out of 1 hunks FAILED -- saving rejects to file browser/components/migration/nsIEdgeReadingListExtractor.idl.rej
file browser/components/migration/nsWindowsMigrationUtils.h already exists
1 out of 1 hunks FAILED -- saving rejects to file browser/components/migration/nsWindowsMigrationUtils.h.rej
patching file mozglue/build/WindowsDllBlocklist.cpp
Hunk #1 FAILED at 467
1 out of 1 hunks FAILED -- saving rejects to file mozglue/build/WindowsDllBlocklist.cpp.rej
patch failed, unable to continue (try -v)
patch failed, rejects left in working directory
errors during apply, please fix and refresh diff-without-whitespace.txt

gijs: can you take a look? Thanks!

Comment 37

[:Gijs (he/him)]

Gah. I landed this yesterday, which would presumably why it doesn't apply now. I assumed pulsebot would auto-comment. Clearly not!

http://hg.mozilla.org/releases/mozilla-beta/rev/eafa73853c61

Comment 38

[Vasilica Tamas, QA [:vtamas]]

Verified on Firefox 43.0a2 (2015-10-18) and Firefox 42 beta 7 (20151015151621) on Windows 10 64-bit. Noticed only a known issue: Bug 1213303

Based on the above mentions, I am marking this bug as Verified since the other issue is tracked separately.