Open Bug 761008 Opened 9 years ago Updated 7 years ago

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

Categories

(Toolkit :: Printing, defect)

12 Branch
x86
Windows 7
defect
Not set
normal

Tracking

()

People

(Reporter: julian.viereck, Unassigned)

Details

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.
I think this is a regression, and regression-range would be very useful.
Cancelling works fine on linux
blocking-b2g: --- → 1.4?
tracking-e10s: --- → ?
Reset of the tracking flags. I don't think that was intended.
Need QA's help to check if this actually affects 1.4.
Keywords: qawanted
Jason - this looks like a desktop bug but ended up in our QA-Wanted queue - is there a different workflow they should be following?
Flags: needinfo?(jsmith)
(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
Flags: needinfo?(jsmith)
> 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.
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
This is actually not relevant to B2G, so I'm clearing the flags.
blocking-b2g: 1.4? → ---
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.