Bugzilla

There's something wrong with the `handled` logic in the muxer. The muxer's `sort` is called many times for the same context as results are added. The `handled` set is recreated each time. So we end up "handling" some of the same results several times per context.

For normal results, that doesn't seem to be a problem. For tip results, their span is 3, so when `sort` does `context.maxResults -= UrlbarUtils.getSpanForResult(result) - 1`, it decreases the `maxResults` by 2, and since the tip result is handled more than once, `maxResults` ends up getting decreased too much, eventually to zero, which is why the view ends up empty. For normal results, `context.maxResults -= UrlbarUtils.getSpanForResult(result) - 1` is just zero, so there's no problem there.

Not sure yet what exactly we should be doing here, whether the handled logic needs to be fixed, or maybe we shouldn't be decreasing `maxResults` at all. I thought that saving the `handled` set per context would fix it, but it doesn't.

There's something wrong with the `handled` logic in the muxer. The muxer's `sort` is called many times for the same context as results are added. The `handled` set is recreated each time. So we end up "handling" some of the same results several times per context.

For normal results, that doesn't seem to be a problem. For tip results, their span is 3, so when `sort` does `context.maxResults -= UrlbarUtils.getSpanForResult(result) - 1`, it decreases the `maxResults` by 2, and since the tip result is handled more than once, `maxResults` ends up getting decreased too much, eventually to zero, which is why the view ends up empty. For normal results, `UrlbarUtils.getSpanForResult(result) - 1` is just zero, so there's no problem there.

Not sure yet what exactly we should be doing here, whether the handled logic needs to be fixed, or maybe we shouldn't be decreasing `maxResults` at all. I thought that saving the `handled` set per context would fix it, but it doesn't.