761008 - Press "cancel" in print progress dialog doesn't cancel printing

Status: RESOLVED INVALID

(Toolkit :: Printing, defect)

Description

[Julian Viereck]

Starting the print process and press the cancel button in the print progress dialog does not abort the printing process.

I've tested this printing the current version of the HTML5 spec which is more then 1.500 pages to print. Pressing cancel ASAP closes the dialog, but if I open the print info window on Windows, I see the number of pages constantly increasing after the cancel is performed.

Testing on Linux, there is as well some printout after the "cancel" button was pressed.

Expected behavior: There should be no printout after pressing the "cancel" button.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

I think this is a regression, and regression-range would be very useful.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Cancelling works fine on linux

Comment 3

[Sylvestre Ledru [:Sylvestre]]

Reset of the tracking flags. I don't think that was intended.

Comment 4

[Ivan Tsay (:ITsay)]

Need QA's help to check if this actually affects 1.4.

Comment 5

[Joshua Mitchell (Inactive)]

Jason - this looks like a desktop bug but ended up in our QA-Wanted queue - is there a different workflow they should be following?

Comment 6

[Preeti Raghunath(:Preeti)]

(In reply to Joshua Mitchell [:Joshua_M] from comment #5)
> Jason - this looks like a desktop bug but ended up in our QA-Wanted queue -
> is there a different workflow they should be following?

Joshua,

This request is for the Taipei QA team to check if this issue is reproduced on 1.4 branch

Comment 7

[Joshua Mitchell (Inactive)]

> Joshua,
> 
> This request is for the Taipei QA team to check if this issue is reproduced
> on 1.4 branch

I see, but do they use different keywords? Our queues (Qanalyst QA) are based on the tag QA-Wanted so now we see it in our list of tasks to complete. As far as I know we do not share a task queue with Taipei but I could be wrong. I just wanted to make sure it was tagged properly to receive the QA work they were expecting to receive.

Comment 8

[William Hsu [:whsu]]

In order to quicken triage speed, Taipei QA team sometimes willing to help answer "qawanted" bug.
But, If Taipei QA team cannot answer these question in time, Qanalyst should help on it, right?

The information I got from Tony.
> Effective immediately, Taipei QA’s team will be taking over full ownership of
> the 1.4 release work.    the US QA team will stop 1.4 regression work (with
> the exception of on-demand QAwanted tasks), and shift focus over to 2.0 and
> 2.1.
>
> TW QA (on Dolphin)
> - will run daily 1.4 smoke tests
> - will participate in all 1.4 triages each week
> - will work with SPRD to file and scrub bugs, also reproduce and test
> 
> US QA
> - halt doing automation and manual 1.4 smoke tests (on Flame)
> - halt participation in triage sessions
> - on-demand support if there are QAwanted bugs that needs additional testing
> (on Flame), that Taiwan QA can’t handle
>
>
> 
> Thanks,
> Tony

Comment 9

[Jason Smith [:jsmith]]

This is actually not relevant to B2G, so I'm clearing the flags.

Comment 10

[Jonathan Watt [:jwatt]]

There is no print progress dialog nowadays.